Project

General

Profile

Bug #11266

Unnested *_id parameters treated as parent resources in API

Added by Dominic Cleal about 7 years ago. Updated almost 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
API
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
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

Related to Foreman - Bug #8343: API resource_scope ignores optionsClosed2014-11-11
Related to Foreman - Bug #13775: Not able to change an HG for a host using API callClosed2016-02-17

History

#1 Updated by Dominic Cleal about 7 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.

#2 Updated by Dominic Cleal about 7 years ago

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

#3 Updated by Dominic Cleal almost 7 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).

#4 Updated by Dominic Cleal almost 7 years ago

  • Legacy Backlogs Release (now unused) deleted (63)

#5 Updated by Dominic Cleal over 6 years ago

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

Also available in: Atom PDF