Project

General

Profile

Actions

Bug #11266

open

Unnested *_id parameters treated as parent resources in API

Added by Dominic Cleal over 9 years ago. Updated about 9 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
API
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

Spotted in #11219, seems to have existed for a while but has gotten worse with #8343.

PUT /api/v2/operatingsystems/4/os_default_templates/2 with

{
    "config_template_id": "40",
    "template_kind_id": "1" 
}

results in:

[ WARN 2015-07-31 08:51:28 app] Action failed
 | NoMethodError: undefined method `name' for nil:NilClass
 | /root/foreman/app/controllers/api/base_controller.rb:55:in `parent_scope'
 | /root/foreman/app/controllers/api/base_controller.rb:46:in `resource_scope'
 | /root/foreman/app/controllers/concerns/find_common.rb:9:in `find_resource'

It looks like the parent_resource_details method is checking the params list for top-level parameters ending in _id and assuming that is likely to be a parent resource. When sending unwrapped parameters, you get a mixture of parameters in the top-level scope, e.g. for the above something like:

=> {"config_template_id"=>"1",
 "template_kind_id"=>"1",
 "format"=>"json",
 "apiv"=>"v2",
 "action"=>"update",
 "controller"=>"api/v2/os_default_templates",
 "operatingsystem_id"=>"6",
 "id"=>"30",
 "os_default_template"=>
  {"template_kind_id"=>"1", "provisioning_template_id"=>"1"}}

Only the operatingsystem_id is the correct parent _id attribute here, the rest are actually part of the user's parameters being submitted.

We use wrap_parameters which copies attributes from the top-level into the nested hash ("os_default_template") which is used for updates/creates.


Related issues 2 (0 open2 closed)

Related to Foreman - Bug #8343: API resource_scope ignores optionsClosedShimon Shtein11/11/2014Actions
Related to Foreman - Bug #13775: Not able to change an HG for a host using API callClosedAmit Karsale02/17/2016Actions
Actions #1

Updated by Dominic Cleal over 9 years ago

I should also note that swapping the order of the attributes in the body changes the behaviour, as it finds template_kind_id instead first. Neither is the correct behaviour.

Actions #2

Updated by Dominic Cleal over 9 years ago

  • Related to Bug #8343: API resource_scope ignores options added
Actions #3

Updated by Dominic Cleal about 9 years ago

https://groups.google.com/forum/#!topic/foreman-users/JvWBGQWqvL0 reports the same issue when using /api/hosts and passing hostgroup_id in the body of the request. It needs nesting under "host" to avoid it being treated as /api/hostgroups/:hostgroup_id/hosts (which causes a 404).

Actions #4

Updated by Dominic Cleal about 9 years ago

  • Translation missing: en.field_release deleted (63)
Actions #5

Updated by Dominic Cleal almost 9 years ago

  • Related to Bug #13775: Not able to change an HG for a host using API call added
Actions

Also available in: Atom PDF