Difference between attr_accessible parameters and strong parameters

I just read a little on attr_accessor , attr_accessible and strong options in several different places:

The difference between attr_accessor and attr_accessible
How is attr_accessible used in Rails 4? http://edgeapi.rubyonrails.org/classes/ActionController/StrongParameters.html

And I look at the mass mission:

http://code.tutsplus.com/tutorials/mass-assignment-rails-and-you--net-31695

I cannot make out the difference between attr_accessible and strong parameters. I am not 100% sure of my understanding of the subjects mentioned above, so I might have missed something simple, but I know that they do a similar job.

However, what is the difference between attr_accessible and strong parameters? Is this a different name for the same thing? Why did we move from one to another?

Any information appreciated.

+7
ruby-on-rails-4 strong-parameters attr-accessible
source share
2 answers

attr_accessible is deprecated in Rails 4 in favor of strong options.

Both options are different approaches to the task of mass assignment, but strong parameters are more flexible.

In the example, you have a User model with email:string and is_admin:boolean attributes. You want to allow users to change their email through the form, but not in the is_admin field.

In Rails 3 you have to do:

 attr_accesible :email 

With this approach, the user cannot change is_admin because this attribute is protected.

One of the good characteristics of strong parameters is that you can do the following in your controller:

 def user_params if current_user.admin? params.require(:user).permit(:email, :is_admin) else params.require(:user).permit(:email) end end 

Thus, one admin user will be able to change is_admin until a regular user does this.

This is just one example, not the best way to grant administrative permissions to a user, but it's pretty illustrative.

The main advantage of Strong Parameters is that they are defined in the controller and can be dynamically assigned at runtime. attr_accessible was a more static and monolithic way of whitelist attributes.

On the other hand, attr_accessor is a completely different thing and can still be used in Rails 4, for example, if you need one attribute in your model that does not need to be stored or written to the database, but you need it in the form. Think about:

attr_accessor :has_accepted_legal_terms

This is a Ruby method that can be used to declare a non-database attribute of your model, a class attribute, or PORO (plain old ruby ​​object).

+14
source share

Strong parameters and attr_accessible are two different ways to add security for the Rails bulk assignment function . Strong parameters are a method which is set by the current version of Rails.

Bulk Assignment is a convenient abbreviated line in Rails that allows you to set many model properties in a single expression.

For example, imagine that you have @user that you want to update with data from a form view. Without mass assignment, you will have to write boring code as follows:

 @user.first_name = params[:user][:first_name] @user.last_name = params[:user][:last_name] @user.phone_number = params[:user][:phone_number] ... @user.save 

And for each form field and for inclusion.

For mass assignment, all of this code becomes one line:

 @user.update(params[:user]) 

But it is full of security holes. . Since params contains any data sent by the browser, an attacker could add data to this view, which you did not expect. For example, they can add is_admin=1 to the parameters. If you have an is_admin database is_admin , then the mass assignment will simply allow the user to go to the administrator. Hop!

Here you will find strong options. With strong parameters, Rails raises ActiveModel::ForbiddenAttributesError if you try to do a naive update(params[:user]) . Instead, you need to clearly indicate what options you expect from the browser view, using the require and permit helpers, which provide strong options. Like this:

 def user_params # Note that :is_admin is not permitted! params.require(:user).permit(:first_name, :last_name, :phone_number) end ... @user.update(user_params) 

I can’t talk about supporting Rails, but I like Strong Parameters because it is flexible. If I have several actions in the user controller that expect different parameters, I can easily describe with permit parameters that should be allowed.

Or, if I have different user roles that are allowed to update different attributes, I can easily model these permissions. As mentioned in CVG Gate, you can even change these permissions at runtime, which is powerful.

In short, the flexibility of strong parameters is due to the fact that you can define this user_params method anywhere and as you like. You fully use the concepts of Ruby and OO to make them work the way you want.

What about attr_accessible ?

Without going into details (since this function is no longer supported by Rails): instead of using the permit method, you would do something similar using the attr_accessible macro in the model itself, for example:

 class User < ActiveRecord::Base attr_accessible :first_name, :last_name, :phone_number ... end 

So, for simple cases, it is very similar to Strong Parameters; you just define a list of attributes elsewhere.

However, since attr_accessible is closely related to the definition of a model class, you lose a lot of flexibility. What if you have two different controller actions that must perform bulk assignment for the same User model? Now you are stuck.

attr_accessor

The attr_accessor macro attr_accessor built into Ruby and has nothing to do with Rails, bulk assignment, or security. It just looks like a similar name. :)

+5
source share

All Articles