In the last movie we created a web form which will submit its values to the create action. Before we implement any form processing in the create action we need to first talk about mass assignment and strong parameters. Mass assignment is the term for passing a hash of values to an object to be assigned to the objects values. New, create and update attributes are the primary methods that do it, but there are others. Rails is making our lives much easier by allowing us to assign values to this object all at once instead of one by one.
Unfortunately this convenience also introduces a major security issue. Imagine that we have a form that lets users update their user name it submits a parameter for user name and then we use update attributes which uses mass assignment to set the attribute user name. Equal to the string that we send in. Now imagine that a hacker is able to submit a fake version of the form and on the fake form, the hacker includes some extra form fields that show up in our params. Rails dutifully grabs all attributes. And mass assigns them to the object before updating the database.
Our imaginary hacker just gained access and admin privileges to our application. If we're going to use the convenience of mass assignment, then we need a way to filter the attributes that are allowed to be mass assigned. Rails is evolved in how this filtering is accomplished. In early versions of Rails, attributes can be declared as protected or disallowed for mass assignment in the model. In programming when everything is available by default and we list only the items that are disallowed, it's called blacklisting. This was optional. Some people ignored it, didn't fully understand it, or made simple forgetful mistakes.
And that left their Rails sites vulnerable. In Rails version 3 filtering evolved into disallowing mass assignment by default and requiring all allowed attributes to be declared. In the model. In programming, when everything is disallowed by default, then we declare the add-ons that are allowed, it's called whitelisting. It's the opposite of blacklisting. Secure by default is a better approach than insecure by default. It had a configuration to turn whitelisting on or off, which some people simply turned off rather than learning to use it properly, again leaving their Rails sites vulnerable.
It was also a problem that these attributes were being declared as accessible or protected in the model. Often when we build applications an attribute is protected when the public submits a form but accessible when an admin submits a form. Rails four solves both of these problems with strong parameters strong parameters can't be turned off with a simple configuration. They are strong, in part, because they are on by default and make it hard for developers to get around them. In some sense, they protect you from yourself. The code for allowing or disallowing attributes has also been moved from the model to the controller, so that each controller can manage its own list of permitted attributes.
All we have to do is tell the params hash what attributes to permit. Permit will mark the attributes as being available for mass assignment. By default, all values in the params hash are now unavailable. We must list the ones for it to allow. Strong parameters also gives us another method called require. Require ensures that the parameter is present. If our attributes hash is assigned to subject, then we need to make sure subject is in the params. require does not do permitting. It does, however, return the value of the parameter.
So in some ways, it's a lot like when we call params[:subject]. It's just adding an extra requirement that it actually be there, or else it'll raise an error. The two of these work together, because now we can call params.require(:subject) And then indicate the attributes that ought to be permitted. Again, this is permit as it relates to mass assignment. Any other parameters will still be in the params hash, and will still be usable as values. They just can't be mass assigned to an object without giving explicit permission.
Now that we understand the problem with mass assignment, and the solution that strong parameters provides, we're ready to process the form for creating a new subject. As we do, we'll remember to permit the attributes that can be mass assigned.
- Why use Ruby on Rails?
- Installing Ruby on Rails on Mac and Windows
- Rendering templates and redirecting requests
- Generating and running database migrations
- Creating, updating, and deleting records
- Understanding association types
- Using layouts, partials, and view helpers
- Incorporating assets using asset pipeline
- Validating form data
- Authenticating users and managing user access
- Architecting RESTful applications
- Debugging and error handing
Skill Level Intermediate
1. What Is Ruby on Rails?
2. Installing Ruby on Rails on a Mac
3. Installing Ruby on Rails on a Windows Machine
4. Getting Started
5. Controllers, Views, and Dynamic Content
6. Databases and Migrations
7. Models, ActiveRecord, and ActiveRelation
9. Controllers and CRUD
10. Layouts, Partials, and View Helpers
13. Data Validation
14. User Authentication
15. Improving the Simple CMS
16. REST and RESTful Routes
17. Debugging and Error Handling
18. Introducing More Advanced Topics
Next steps1m 40s
- Mark as unwatched
- Mark all as unwatched
Are you sure you want to mark all the videos in this course as unwatched?
This will not affect your course history, your reports, or your certificates of completion for this course.Cancel
Take notes with your new membership!
Type in the entry box, then click Enter to save your note.
1:30Press on any video thumbnail to jump immediately to the timecode shown.
Notes are saved with you account but can also be exported as plain text, MS Word, PDF, Google Doc, or Evernote.