A Rule of Thumb for Strong Parameters

Development

Reading Time: 7 minutes

This article was originally published on Pat Shaughnessy’s personal blog. With his kind permission, we are sharing it here for Codeship readers.

security
It can be hard to open the Strong
Parameters door and let permitted
values into your Rails 4 app.

Last week I banged my head against the wall for a few hours trying to figure out how to whitelist input values for my Rails 4 app using the Strong Parameters feature.

Calling permit when you have a simple attributes hash for a single new object is straightforward, but figuring out how to call permit for a complex, nested set of attributes can be nearly impossible.

TL;DR: Use this rule of thumb when trying to figure out how to whitelist nested attributes:

  • To Permit a Hash, Pass an Array
  • To Permit an Array, Pass a Hash

After studying the problem for a while, I noticed this curious pattern: To whitelist a simple hash of attributes, you pass permit an array. To whitelist an array of nested objects, you pass it a hash, including that hash in the surrounding array.

Not familiar with Strong Parameters yet? What do I mean by “whitelist?” Why do you need this rule of thumb? My post today will explain.

To Permit a Hash, Pass an Array

Rails 4 requires you to whitelist or authorize input values for your app. This important new feature, known as Strong Parameters, adds an extra layer of security that prevents attackers from posting harmful or garbage information to your site.

Here’s how it works: Suppose you have a Post model with title and body columns. Using Rails 4, you would write a create controller action like this:

simple_controller

Here you first tell Rails which attributes are allowed for new post objects — title and body in this example — and then you create the new post. This is simple enough and quite readable. You are telling Rails: “Data for a post is required, and its attributes may only include title and body attributes.”

diagram1

In the diagram above you can see the post attribute hash on the left and the arguments for permit on the right. Notice the arguments are actually a single array (internally Rails processes the arguments as an array). Each key/value pair on the left maps to an array element on the right. You permit a hash by passing an array.

Strong Parameters Confusion

However, now suppose you add a second model to your app, Comment. Let’s suppose a post has many comments, and each comment has a single text attribute.

has-many

Because your app is a REST-ful JSON service (what else do people use Rails for these days?) you have a requirement to create a post and its comments from a single JSON string:

json

Because the comment array is named “comments” you assume Active Record will create the associated comment models along with the new post. That is, Active Record should call comments= on the new post and pass in the comment attributes. But it doesn’t work. Instead, using the code from earlier you get:

warning

Ah — you forgot to whitelist the comments attribute. You try adjusting the call to permit:

permit-comments

It still doesn’t work. You get the same warning:

warning

Clearly Rails isn’t listening! You just told it comments is permitted — why does Rails give you the same warning again? Maybe you need to create the comment objects yourself, as a separate step:

create-comments

Now things are even worse: Rails raises an exception!

exception

The problem here is that the Comment model is complaining that you haven’t whitelisted its attributes. Somehow each Active Record model has knowledge about which attributes were whitelisted and which weren’t!

If you happened to know that Rails 4 saves the parameters inside an ActionController::Parameters object, you could try creating a separate instance of this class for each comment, and whitelist its text attribute directly:

permit-comments2

But you’ll still get the same “Unpermitted parameters” warning when you try to create the post next — not to mention that your code has become incredibly confusing and verbose. What’s going on here? There must be some way of creating nested objects without warnings or exceptions.

To Permit an Array, Pass a Hash

The solution is to permit all the post and comment attributes with a single call to ActionController::Parameters#permit, like this:

nested-solution

What? What does the complex argument list to permit mean? How in the world would anyone know to pass that in?

My rule of thumb can help. In this example, you are permitting an array of comments by passing a hash. Imagine if your app received a post with two comments, like this:

diagram2

On the left you see the nested attributes for the post and its comments. Rails has parsed this for you from a JSON string. On the right are the arguments you pass to permit. Notice how the hash of post attributes contains an array for the comments — in the call to permit you replace this array with a hash! To permit an array, pass a hash.

This hash, in turn, contains an array listing the attributes of each comment object (just [:text] here).

Sign up for a free Codeship Account

Whitelisting Rails Nested Attributes

Note: If your Rails app was in fact a web site, you might use the Rails nested attributes feature with a complex HTML form. In this case, you would declare that posts accept nested attributes for comments, directing Active Record to automatically create the comment objects for you:

accepts-nested

To make this work you will need to adjust your call to permit slightly:

nested-attribs-permit

With accepts_nested_attribute_for, Rails expects the comments to be saved as comments_attributes. Also, each comment must have an id attribute in order for the web forms to update existing comments properly. (Also, Rails represents the comment array as a hash, with the id as the key for each comment.)

But the syntax is almost the same, and the same rule applies: To permit an array of comments you, call permit with a hash.

Under the Hood

Internally, Rails uses a trick to tell Active Record which attributes were permitted and which weren’t. Here’s how it works:

hashes

On the left is a normal hash — you can create an Active Record model using this hash without worrying about whitelisting parameters. On the right is an ActionController::Parameters object; notice it looks almost the same. ActionController::Parameters is actually a subclass of Hash (via ActiveSupport::HashWithIndifferentAccess).

But on the right notice that the ActionController::Parameters object contains a permitted? method. This tells Active Record whether the attributes in that hash were whitelisted or not.

When you create a new post or any ActiveRecord::Base object, code inside of Rails checks whether the attributes hash implements the permitted? method or not:

internals1

Because a normal hash doesn’t respond to permitted?, Active Record creates the new post without complaining.

However, if you try to create a post from an ActionController::Parameters object, Rails finds the permitted? method:

internals2

If you didn’t whitelist this hash using a call to permit, permitted? will return false and Rails will raise the ActiveModel::ForbiddenAttributesError exception.

Still Confused? Just Use a Normal Hash

If all of this is still confusing you — if you’re still having trouble figuring out the call to permit properly for your complex JSON input — then remember you can always just use normal hashes instead of ActionController::Parameters objects.

For example:

normal-hashes

Here you are whitelisting or permitting each attribute manually by copying them into normal hashes. Since Hash doesn’t implement permitted?, Active Record won’t raise an ActiveModel::ForbiddenAttributesError exception.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.



We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.