rails: Strong parameters: allow hashes with unknown keys to be permitted

None of the workarounds suggested in this thread seemed to work for me (Rails 4.2.4), so I devised the following workaround:

def product_params
  properties_keys = params[:product][:properties].keys
  params.require(:product).permit(:title, :description, properties: properties_keys)
end

Hope that helps someone.

Hey @fxn and @senny, it’s the year of 2016 now. Rails got background jobs and even websockets, things that were originally neglected/ignored. Since 2013, the use of free-form JSON and Hstore values has rapidly grown too, and maybe it’s high time to not ignore them either. The values submitted to them are free-form by design, therefore not subject to any whitelisting/filtration. But they don’t live alone. They live inside models whose fields are whitelisted and filtered against mass assignment.

Consider Stripe gateway. They allow users to store free-form metadata on customer object, and that’s just a hash. How to achieve that in Rails if the JSON request looks like this: POST /customers, {description: …, source: …, metadata: {… free form data here…}}. Answer: fight the framework - and many people in this thread did it their own way. Currently, if there’s any JSON field without a predefined “schema” inside the params, Strong Parameters has to be worked around for each field. In 2016, letting a non-checked JSON in is a common situation.

There’s already @sdepold’s pull request to allow this here: https://github.com/rails/strong_parameters/pull/231. I hope you can reevaluate this feature and give it a green light. If there’s any issue/feedback about that PR, I can take it over from the original submitter and finish it up if he’s unreachable. Please let me know.

Another possibility which I think I like even better would be to allow permit! to take an optional parameter, to allow this:

params.require(:product).permit(:name).permit!(:data)

Implemented here.

Confirm, the API is designed to whitelist every single key. If your use case does not fit well then you need to resort to Ruby. That flexibility is also by design, in the end it is just Ruby.

For nested params I now use the following:

def item_params
  params.require(:item).permit(values: permit_recursive_params(params[:item][:values]))
end

def permit_recursive_params(params)
  params.map do |key, value|
    if value.is_a?(Array)
      { key => [ permit_recursive_params(value.first) ] }
    elsif value.is_a?(Hash) || value.is_a?(ActionController::Parameters)
      { key => permit_recursive_params(value) }
    else
      key
    end
  end
end

Edit: Updated version can be found in this gist

To avoid duplication set the trusted parameter in the helper (untested):

def product_params
  params.require(:product).permit(:name).tap do |whitelisted|
    whitelisted[:data] = params[:product][:data]
  end
end

Rails 5 workaround -

def product_params
      load_params = params.require(:product).permit(:name)
      load_params[:json_data] = params[:product][:json_data]
      load_params.permit!
end

I realize this doesn’t whitelist the data within the json_data param, but it excludes same-level unpermitted params.

Oh and hi @stevebissett 👍

strong parameters is not designed to handle every possible situation. We wanted to keep the API on point to handle the most common situations.

Understand, but this doesn’t exactly seem like an uncommon use case (particularly with the introduction of Hstore and JSON types), and with attr_accessible/attr_protected being removed from Rails core, options are severely reduced.

I would argue that this actually makes the API more consistent, since permit! would accept a list of keys, closely mirroring permit.

As assigning a hash with unknown keys more or less defeates the purpose of strong parameters (restricting allowed keys), It’s not supported because it could make your code vulnerable.

Except you’d only be permitting an unknown hash on a single key within the params. It’s certainly more secure than doing a permit! on the whole params hash (which is supported behaviour).

As you mentioned already you can simply fall back on a normal assignment if you know that you want to permit unknown keys.

My main problem with this is that I go from having to test one message (Product.create) to having to test three messages (Product.new, @product.data= and @product.save). The separate assignment for my hash also has to be duplicated across both my create and update actions.

Here’s a concrete example of how my proposal would improve things. Before:

class ProductsController < ApplicationController
  def create
    @product = Product.new(product_params)
    @product.data = params[:product][:data]
    @product.save!
  end

  def update
    @product = Product.find(params[:id])
    @product.data = params[:product][:data]
    @product.update!(product_params)
  end

private
  def product_params
    params.require(:product).permit(:name)
  end
end

After:

class ProductsController < ApplicationController
  def create
    @product = Product.create!(product_params)
  end

  def update
    @product = Product.find(params[:id])
    @product.update!(product_params)
  end

private
  def product_params
    params.require(:product).permit(:name).permit!(:data)
  end
end

I do think this needs more discussion. It’s all well and good to say just do it manually, but it feels wrong to have to work around a feature (and make my code more complicated), particularly when the alternatives have been removed.

I modified @PandaWhisperer solution to safeguard against non-existing key:

def product_params
  properties_keys = params[:product].try(:fetch, :properties, {}).keys
  params.require(:product).permit(:title, :description, properties: properties_keys)
end

In the majority of these comments, the keys are known. This thread’s subject was for unknown keys.

A few of the better workarounds are:

• explicit permit! of a nested hash : https://github.com/rails/rails/issues/9454#issuecomment-280853714
• Adding a permit_recursive_params function : https://github.com/rails/rails/issues/9454#issuecomment-199357625

Fix is coming in 5.1.2 https://github.com/rails/rails/commit/e86524c0c5a26ceec92895c830d1355ae47a7034

Running on Rails 4.2.6 this works for me:

def user_params
  params.require(:person).permit(:name, :description, :age, custom_attributes: [:key, :value])
end

This will allow the following params to be permitted:

{
  "person": {
    "name": "John",
    "description": "has custom_attributes",
    "age": 42,
    "custom_attributes": [
      {
        "key": "the key",
        "value": "the value"
      }
    ]
  }
}

This can be seen in the source here: https://github.com/rails/rails/blob/bdc73a438a97f2e0aceeb745f4a95f95514c4aa6/actionpack/lib/action_controller/metal/strong_parameters.rb#L522

If you don’t know what might be in custom_attributes you could do

def user_params
  params.require(:person).slice(:name, :description, :age, :custom_attributes) 
end

Perhaps this is overkill, but one simple workaround that I didn’t see here is as follows:

params.permit( ... ).merge(params.to_unsafe_hash.slice(:json_data))

The other workarounds don’t appear to work for arbitrarily nested hashes and arrays.

Patch versions don’t have new features, this is going to come with 5.1.

@Nowaker agree, we’ve been conservative, but time says this use-case deserves a dedicated API.

The :* proposal seems good to me. The patch would need some work, but the basic idea of a wildcard symbol to say “accept whatever here” might work.

The patch is no big deal, I might write one based on that PR (and give credit of course).

@olmesm

def product_params
      load_params = params.require(:product).permit(:name)
      load_params[:json_data] = params[:product][:json_data] if params[:product][:json_data]
      load_params.permit!
end

need to add a if condition otherwise it add a nil value for json_data, which causes issue if you call update on an object with the param

but good workaround, thank you!

that’s a sufficient workaround but hardly a good solution. what about params.require(:product).permit(:name, :data => Hash) and allowing Hash as a permitted scalar value IF it is explicitly defined.

This thread started quite a while ago, but it’s still active, so here’s something I just discovered. I was able to permit a jsonb attribute to my User model with the syntax normally used with accepts_nested_attributes_for:

def user_params
  params.require(:user).permit(:email, :password, data: [:one, :two, :three])
end

Where data is your json attribute, and the array of properties are what you wish to permit. I’m not sure if this is functioning as intended by Rails, or if it just works through some fluke. It may not work with every use case, or with deeply nested attributes, but I’m curious to see how it works for others here. I’m using Rails 5.1.1.

I modified @PandaWhisperer solution to safeguard against non-existing key:

def product_params properties_keys = params[:product].try(:fetch, :properties, {}).keys params.require(:product).permit(:title, :description, properties: properties_keys) end

@aliibrahim thanks, that worked for me!

it would be nice if it also allow to set structure incoming hash, like a

params.permit(preferences: [{:scheme, font: {:name, :size}}])

for next cases in params:

params = ActionController::Parameters.new(
    username: "fxn",
    preferences: [
        {
            scheme: "Marazul",
            font: {
                name: "Source Code Pro",
                size: 12
            }
        },
        {
            scheme: "new scheme",
            font:
                {
                    name: "Another Font",
                    size: 14
                }
        }
    ])

This monkey patch can help: https://gist.github.com/iagopiimenta/43a66712c021a9d3f540#file-monkey_patch_rails_parameters-rb-L21

It can be used like this:

params = ActionController::Parameters.new(
  form: {
    scalar: 'foobar',
    many: [
      {
        field1: 'foo'
      },
      {
        fiedl2: 'bar'
      }
    ],
    single: {
      filed3: 'baz'
    }
  }
)

params.require(:form).permit(:scalar, many: Hash, single: Hash)

@anklos your example work, saves the data correctly (thx alot)

but

It still complains about the concerned json column being unpermitted. Is that normal ?

@spohlenz i have faced similer problem and after lot of googling and going through various stackoverflow Q/A was still not able to figure out good solution. So, i tried myself some hack. So, here what i did params = ActionController::Parameters.new(driver: { driver_data: { name: “zyx”, address: “adfasf” } }) driver_data_keys = params[:driver][:name].keys params.require(:driver).permit(driver_data: [driver_data_keys])

Advantages

• Do for rails 4.
• I know it is a hack, but still it is looking good than i have found different solution.
• it is the best soluion for whiltlisting any or any no of key withuto getting worried about handling it. I hope it will help. Happy coding.

@Nowaker I can’t turn that into a hash, because I need multiple of them, (edited slightly).

@uberllama I have modified your answer a little and it worked nicely for any number of dynamic keys. Example params: post: { something: {...}, something_else: {...} }

  def post_params
    permit_key_params(params[:post]) do
      params.require(:post)
    end
  end

  def permit_key_params(hash)
    permitted_params = yield
    hash.keys.each do |key|
      values = hash.delete(key)
      permitted_params[key] = values if values
    end
    permitted_params
  end

I think, This will help,

params.require( :knockouts ).permit(params[:knockouts].keys.map {|c| {:"#{c}" => [:volume, :temperature]}})

@fxn agree, that’s an acceptable solution. @nhattan, I ended up adding testing for nil value.

def product_params
  params.require(:product).permit(:name).tap do |whitelisted|
    whitelisted[:data] = params[:product][:data] if params[:product][:data]
  end
end

fyi, the approach in #12609 is not feasible for hashes of a depth greater than 2.

The solution mentioned by @fxn only works if you have decided to log instead of raise when un-permitted parameters are present. There are plenty of situations (metadata, configuration, etc.) where whitelisting a sub-hash is completely valid.

I think that @spohlenz solution might be the most similar and I will have to implement something like it.

@hakanensari I’m not sure if duplicating the guides in the README is a good thing. They will get out of sync quickly. I’d like to keep the additional examples in the guides because they are the reference for Rails.

Maybe we could link from the README to the relevant section in the guides? (http://guides.rubyonrails.org/action_controller_overview.html#more-examples)

@fxn what do you think?