StrongParameters#permit has inconsistent behavior with numeric-looking keys

[nightpool]

Steps to reproduce

params = ActionController::Parameters.new(items: {'1': {x: 2, y: 3}, '2': {x: 3, y: 4}})

params.require(:items).permit('1': [:x, :y], '2': [:x])
#  {"1"=>{"x"=>2, "y"=>3}, "2"=>{"x"=>3}}

params.permit(items: {'1': [:x, :y], '2': [:x]})
#  {"items"=>{"1"=>{}, "2"=>{}}}

Expected behavior

Permit should behave the same when called on a parent hash as it does when called on a child hash.

Actual behavior

Permit's behavior is inconsistent, and it's very difficult and confusing to permit a nested hash with integer-like keys. More generally, when dealing with JSON parameters, the implicit "array-like" handling behavior should be limited to real, actual arrays—not just objects with keys that look like numbers.

System configuration

Rails version: 6.0.2.2

Ruby version: 2.6.3

[markvanlan]

you can see how the current test for numberic keys here:

rails/actionpack/test/controller/parameters/nested_parameters_permit_test.rb

Lines 128 to 151 in dc7817c

	test "nested params with numeric keys" do
	params = ActionController::Parameters.new(
	book: {
	authors_attributes: {
	'0': { name: "William Shakespeare", age_of_death: "52" },
	'1': { name: "Unattributed Assistant" },
	'2': { name: %w(injected names) }
	}
	})
	permitted = params.permit book: { authors_attributes: [ :name ] }
	assert_not_nil permitted[:book][:authors_attributes]["0"]
	assert_not_nil permitted[:book][:authors_attributes]["1"]
	assert_empty permitted[:book][:authors_attributes]["2"]
	assert_equal "William Shakespeare", permitted[:book][:authors_attributes]["0"][:name]
	assert_equal "Unattributed Assistant", permitted[:book][:authors_attributes]["1"][:name]
	assert_equal(
	{ "book" => { "authors_attributes" => { "0" => { "name" => "William Shakespeare" }, "1" => { "name" => "Unattributed Assistant" }, "2" => {} } } },
	permitted.to_h
	)
	assert_filtered_out permitted[:book][:authors_attributes]["0"], :age_of_death
	end

You can just do params.permit(items: [:x, :y]) for the case you gave.

@fxn I see you wrote this test. I can reproduce what @nightpool says here; if those keys are non-numeric the permit would work. I can work on a fix for this if it is a bug worth fixing; not sure because the answer is use the structure I suggested above.

[nightpool]

Mark, in this case I need to permit different parameters for different IDs—your workaround would allow the parameter "y" in for the second object, which in some cases may be undesired.

…

On Tue, Mar 9, 2021, 10:17 AM Mark VanLandingham ***@***.***> wrote: you can see how the current test for numberic keys here: https://github.com/rails/rails/blob/dc7817cb42768ad01d69d5f9b0023f556760cb06/actionpack/test/controller/parameters/nested_parameters_permit_test.rb#L128-L151 You can just do params.permit(items: [:x, :y]) for the case you gave. @fxn <https://github.com/fxn> I see you wrote this test. I can reproduce what @nightpool <https://github.com/nightpool> says here; if those keys are non-numeric the permit would work. I can work on a fix for this if it is a bug worth fixing; not sure because the answer is use the structure I suggested above. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#41625 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCV3HVAYCWVQNKIME2J3TCY3X5ANCNFSM4YVUGCYQ> .

[markvanlan]

You're basically want to rely on an index to determine what params are permitted... Seems like a bad pattern honestly. Does seem like it should work, however.

[nightpool]

@markvanlan nope, nothing to do with an index. The structure in question was a map from models IDs to new instances of those models with specific attributes. So in this case, what might be an acceptable attribute for one model class might be dangerous for another.

[rails-bot]

This issue has been automatically marked as stale because it has not been commented on for at least three months.
The resources of the Rails team are limited, and so we are asking for your help.
If you can still reproduce this error on the 6-1-stable branch or on main, please reply with all of the information you have about it in order to keep the issue open.
Thank you for all your contributions.

[nightpool]

This is still an issue, reproduction steps are the same as above! When dealing with JSON parameters, the implicit "array-like" handling behavior should be limited to real, actual arrays—not just objects with keys that look like numbers. This is a very confusing behavior and it took me a long time to figure out why strong parameters was seemingly just not working!

[HParker]

@nightpool if you want to try out the main branch permitting parameters this way is possible now.