strong parameters permit all attributes for nested attributes

Question

Is there a way in strong parameters to permit all attributes of a nested_attributes model? Here is a sample code.

class Lever < ActiveRecord::Base
 has_one :lever_benefit
 accepts_nested_attributes_for :lever_benefit
end

class LeverBenefit < ActiveRecord::Base
  # == Schema Information
  #  id          :integer          not null, primary key
  #  lever_id    :integer
  #  explanation :text
end

For lever strong parameters i am writing currently this

def lever
 params.require(:lever).permit(:name,:lever_benefit_attributes => [:lever_id, :explanation])
end

Is there a way for nested attributes i can write to permit all attributes without explicitly giving the attributes name like lever_id and explanation ?

Note: Please don't get confused with this question with permit! or permit(:all) this is for permitting all for nested attributes

try reading this answer may be this is helpful. > http://stackoverflow.com/questions/14483963/rails-4-0-strong-parameters-nested-attributes-with-a-key-that-points-to-a-hash — Sachin Singh, Jul 23 '13 at 13:46
thanks, but i have seen this. If you notice it's doing the same thing of selective attribute filtering( `assets_attributes: :filename` ) which is passing filename. I want to permit all parameters for nested attributes — AnkitG, Jul 23 '13 at 13:53

tfischbach · Answer 1 · 2017-10-09T11:33:39.760

59

The only situation I have encountered where permitting arbitrary keys in a nested params hash seems reasonable to me is when writing to a serialized column. I've managed to handle it like this:

class Post
  serialize :options, JSON
end

class PostsController < ApplicationController
  ...

  def post_params
    all_options = params.require(:post)[:options].try(:permit!)
    params.require(:post).permit(:title).merge(:options => all_options)
  end
end

try makes sure we do not require the presents of an :options key.

edited Oct 09 '17 at 11:33

answered Aug 16 '13 at 15:26

tfischbach

3,003
3
22
16

Thank You so much,You save my lots of time :) – Jigar Bhatt Mar 24 '15 at 13:34
2

This is the correct answer! you deserve a green checkbox! – Blair Anderson Apr 16 '15 at 21:29
2

Why `params.require(:post).fetch(:options, nil)` instead of `params.require(:post)[:options]`? – Patrick Brinich-Langlois Feb 28 '17 at 22:25
@PatrickBrinich-Langlois Also cannot remember, where the `fetch` came from. Updated the answer. – tfischbach Oct 09 '17 at 11:34

score 20 · Answer 2 · answered Mar 26 '20 at 00:45

20

I am surprised at no one suggested this:

params.require(:lever).permit(:name,:lever_benefit_attributes => {})

answered Mar 26 '20 at 00:45

Jungong Shi

241
2
9

It allows any attributes within the hash in `lever_benefit_attributes`. Works for me, – Ian Vaughan Apr 01 '20 at 12:34
1

Three hours and many headaches later, I'm surprised too. Perfect for my jsonb column within devise_parameter_sanitizer. – Alberto T. Jul 07 '20 at 15:46
I have a parameter with 3 layers of nested arrays with dynamic values and this permits everything. Many thanks! – Rob Carpenter Jun 25 '23 at 21:33

score 17 · Answer 3 · answered Sep 25 '14 at 21:02

Actually there is a way to just white-list all nested parameters.

params.require(:lever).permit(:name).tap do |whitelisted|
  whitelisted[:lever_benefit_attributes ] = params[:lever][:lever_benefit_attributes ]
end

This method has advantage over other solutions. It allows to permit deep-nested parameters.

While other solutions like:

nested_keys = params.require(:lever).fetch(:lever_benefit_attributes, {}).keys
params.require(:lever).permit(:name,:lever_benefit_attributes => nested_keys)

Don't.

Source:

https://github.com/rails/rails/issues/9454#issuecomment-14167664

This will not work for deep-nested params in Rails 5. See why here: http://eileencodes.com/posts/actioncontroller-parameters-now-returns-an-object-instead-of-a-hash/ — rmcsharry, Feb 19 '17 at 22:50

score 12 · Answer 4 · edited May 23 '17 at 12:34

First, make sure that you really want to allow all values in a nested hash. Read through Damien MATHIEU's answer to understand the potential opening of security holes...

If you still need/want to allow all values in a hash (there are perfectly valid use cases for this, e.g. storing unstructured, user-provided metadata for a record), you can achieve it using the following bits of code:

def lever_params
  nested_keys = params.require(:lever).fetch(:lever_benefit_attributes, {}).keys
  params.require(:lever).permit(:name,:lever_benefit_attributes => nested_keys)
end

Note: This is very similar to tf.'s answer but a bit more elegant since you will not get any Unpermitted parameters: lever_benefit_attributes warnings/errors.

score 6 · Answer 5 · answered Nov 02 '13 at 21:12

6

try

params.require(:lever).permit(:name, leave_benefit_attributes: LeaveBenefit.attribute_names.collect { |att| att.to_sym })

answered Nov 02 '13 at 21:12

seufagner

1,290
2
18
25

Damien MATHIEU · Accepted Answer · 2015-08-07T07:47:42.390

-5

The whole point of strong parameters is in its name: make your input parameters strong.
Permitting all the parameters would be a very bad idea, as it would permit anyone to insert values you don't necessarily want to be updated by your users.

In the example you give, you mention the two parameters you currently need to provide:
[:lever_id, :explanation].

If you permitted all the parameters, it would be possible for somebody to change any other value.
created_at, or lever_id for example.

This would definitely be a security issue and this is why you should not do it.
Explicitely specifying all your attributes might seem boring when you do it.
But this is necessary to keep your application secure.

Edit: For people downvoting this. This may not be the answer you're looking for, but it is the answer you need.
Whitelisting all nested attributes is a huge security flaw that strong params is trying to protect you with, and you're removing it.
Take a look at what lead to building strong_params, and how not using it can be bad for you: https://gist.github.com/peternixey/1978249

edited Aug 07 '15 at 07:47

answered Jul 23 '13 at 14:01

Damien MATHIEU

31,924
13
86
94

1

thanks, your answer is a valid point that it can be a security concern. I will go with explicitly mentioning the attributes. – AnkitG Jul 23 '13 at 14:17
30

If the hash you were receiving is stored in a serialised JSON column then there are no security concerns for the keys. (Other than existing concerns of too large an input). I have this use case and I would like to permit any arbitrary key in a hash. – Matt Connolly Jan 10 '14 at 00:43
2

There are other ways of securing attributes. Command objects that toss out unpermitted parameters, for example, are a much better approach, IMHO. – Keith Gaddis Apr 14 '14 at 17:20
Even though I didn't directly answer the question, I believe I provided much better advice. Permitting all attributes is potentially a huge security issue and should **never** be done. – Damien MATHIEU Sep 23 '14 at 20:41
15

There are legitimate use cases where you would want to allow for adhoc params, like a serialized object with a loose or non-existent schema. This DOES happen quite a bit more often than *never* – Dave Rapin Oct 13 '14 at 13:01
5

This is a BAD answer. SO is for solving problems, not telling people how what they are doing is wrong. According to me, these types of answers should only be regarded as valid if they include alternative solutions to what the author might be trying to do. Like for e.g. refer to the anwers below. – Andreas Jun 13 '16 at 13:26
1

If so, then the :permit! method should be removed from the API, which it isn't the case. There are scenarios where you're sure you want to permit everything. – dferrazm Jan 30 '19 at 19:24
Yes, the permit syntax in rails has an open issue because it can't deal with 2D arrays, for instance. I think one's only option in those cases is to use a permit! equivalent – duhaime Mar 18 '22 at 21:50

strong parameters permit all attributes for nested attributes

6 Answers6

Linked

Related