36

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

AnkitG
  • 6,438
  • 7
  • 44
  • 72
  • 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

6 Answers6

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.

tfischbach
  • 3,003
  • 3
  • 22
  • 16
20

I am surprised at no one suggested this:

params.require(:lever).permit(:name,:lever_benefit_attributes => {})
Jungong Shi
  • 241
  • 2
  • 9
17

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

nothing-special-here
  • 11,230
  • 13
  • 64
  • 94
  • 3
    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
12

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.

Community
  • 1
  • 1
severin
  • 10,148
  • 1
  • 39
  • 40
6

try

params.require(:lever).permit(:name, leave_benefit_attributes: LeaveBenefit.attribute_names.collect { |att| att.to_sym })
seufagner
  • 1,290
  • 2
  • 18
  • 25
-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

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