You already know how to build a basic web application with the Ruby on Rails framework. Perhaps, you have even taken Course 1, "Ruby on Rails: An Introduction" (we highly recommend it) where you relied on external web services to be your “data layer”. But in the back of your mind, you always knew that there would come a time when you would need to roll up your sleeves and learn SQL to be able to interact with your own relational database (RDBMS). But there is an easier way to get started with SQL using the Active Record Object/Relational (ORM) framework. In this course, we will be able to use the Ruby language and the Active Record ORM framework to automate interactions with the database to quickly build the application we want.
In Rails with Active Record and Action Pack, we will explore how to interact with relational databases by using Active Record, a Ruby gem, which Rails uses by default for database access. We will then take a look at what role Active Record plays in the overall request-response cycle, when a client (the browser) requests data from the server, as well as how to submit the data to the server. Of course, when accessing data, security is of paramount importance! We will talk about vulnerabilities such as SQL injection, as well as how to secure access to data by authenticating and authorizing users accessing the data. Take this course to build a Ruby on Rails application with Active Record to automate the detailed SQL interactions with our database.

YV

This course continues the Introduction with the same test-driven approach and delicious intensity of the material. Efforts to finish the course will be greatly rewarded.

SJ

Jun 05, 2016

Filled StarFilled StarFilled StarFilled StarFilled Star

I really liked writing the authentication myself. I've relied on Devise (and will continue using it mostly) but really got an appreciation for what was going on.

From the lesson

Introduction to Action Pack

In this module, we will introduce Rails' Action Pack, which is a combination of Action Controller and Action View. We will see how REST has influenced routing in a Rails application and also talk about partials, form helpers, and layouts.

Taught By

Kalman Hazins

Adjunct Professor, Graduate Computer Science

Transcript

[MUSIC] Hi and welcome to lecture six. In this lecture, we'll talk about strong parameters, Flash, and finally, see the code for how we create action works. So strong parameters, as excellently described in the guides, is basically following an idea. With strong parameters Action Controller parameters are forbidden to be used in Active Model, basically your Active Record Model mass assignments until they have been white-listed. This means, you'll have to make a conscious choice about which attributes to allow for mass updating, again the key word here is mass updating and thus prevent accidentally exposing that which shouldn't be exposed. So what does this mean anyways? So if you look at the code for the create action the idea should be is that you have all this parameters coming in and we already saw that there's this params helper in a rails which basically has all request parameters in it so you should be able just to say pass over parameters in here into the new method. And that will create for you an instance of a new post and then you should be able to save it to the database. Now, why is this a problem? Well first of all, it's a good thing because we don't have to specify every parameter that came in. What I'm have to say, Post.name=params.name and so on, right. We could just pass in whole bunch of parameters in and let active record deal with a hash of request parameters, that's the good news. The bad news is let's say this would be an account, a model and you wanna let the user update his name but not his status as an admin. And let's say if there's an attribute called admin in your account data model. So, the issue is that the hacker, if the person's a hacker, he could pass in an admin parameter, or some kind of a parameter that's not meant to be updated in this action as one of the parameters. And the create action would gladly save that attribute to the database. So what strong parameters does, it says no, you can't just use params, instead you have to use post params, which is a method which basically sanitizes your params. So it says the params needs to have a post request parameter, and that post parameter can only have title and content attributes that will be updated. And if any of the analysis is passed in, that should not be inserted or updated to your database. So that's what this is doing. You have a post params, which sanitizes, which filters, which parameters that are allowed to be used. Then you pass those parameters to your post model, that creates a post variable. So that's where the strong parameters part of this ends. At this point, it depends on a format. If we're gonna pass the format in, then we're gonna try to save it for any format. Now at this point if a format is HTML we're gonna redirect to a post, which will basically do a redirect to a show action and display what was just created with notice and we'll get them to explain in this notice in a minute. And format.json, if it's a json format, then do something else and specify a location of a post and send that back to the client that requested the json format. If a saved action fails, so post.save returns true. If it's not true, it'll be false. So then re-render the action, rerender the form, and if it's json, then send back the errors. So now if you don't have a strong parameters implemented, so basically let's say instead of saying post params, we just say params and pass the params back to the model, what you're gonna see is that you get back this exception that says ActiveModel::ForbiddenAttributesError. Which basically means that you're not allowed to use any attributes because you haven't white listed them yet. So as you can see here the parameters coming in are your post title and your post content with certain values. But you haven't white listed them yet, so your post model would not be allowed to use them in this post.new(past_parems) in Flash. Let's talk about Flash. So we wanna redirect the user to a different page on our site, right. So for example in the case of a create, or as we saw in the case of a destroy, we don't have a create template or destroy template so we wanna tell the browser to go to a different page. Let's say to our show action page, our show action template. But at the same time, we want this to be an interaction. We want the message to show up that says, for example, post created or post destroyed. So, how do we do that? So, the solution is to have a flash which is just a hash where the data is put into a hash. And this data persists for exactly one request after the current request. So, usually your browser and the server know nothing about each other, your browser sends a request the server responds, when the browser sends the next request the server has no idea that the browser already previously sent the request. In this case, as we're gonna see, as actually we're seeing right now, rail has used what's called a flash, which is basically just your regular http session, but that http session is killed after the one request right after the current request. That's where it's called flash, basically it's a very short term connection, very short term HTTP session that exists within the browser and the server and once a message is displayed there, it's a post created or a post destroyed, that message is destroyed from the HTTP session and then again that connection is brand new. And the server and the browser don't know that they're interacting with each other. So how do you put stuff into the flash? Well you could just say flash, attribute and the value. But, two very common attributes, the notice attribute and the alert attribute. And these are so common that you have a notice and alert keys which are available to redirect to helper. So instead of saying flash[ equals a certain value and then saying redirect_to, you could just pass these two keys, the notice key or the alert key depending on if there's an error or not, directly into a direct helper. So, when we're creating our post, we do a create action and if it's successful what happens is we get redirected to show.html.erb template. And there's a notice in this flash hash, and that gets displayed, as you remember, the show template has this notice helper and on top, it basically says display a notice helper. In summary, strong parameters require you to whitelist the parameters that you intend to either create or update. And you need this specifically for the case of mass assignment when you want to be lazy, rightfully so, and just pass in a whole bunch of parameters into your hash and be able to create or update your model this way. If you were to just specify exactly which parameters you wanna update, you don't need the strong parameters method. But usually, let's say you would have multiple parameters, and there's no reason to have multiple lines that say, well, post.name equals this, post.that equals that. Instead you actual wanna pass the hash of parameters in. You wanna mass update the model but because of a security risk, you have to specify exactly which parameters are allowed to be updated. And the second thing is flash, and flash persists for exactly one request after the current request/response cycle, and that is the whole purpose of this flash with short-term memory that remembers the interaction between the browser and the server and stores the information in a hash. Next, we'll talk about edit and update actions. So in this case, the new and create actions work together and, as we're gonna see, edit and update actions work together as well. And are actually remarkably close to how the new and create actions work.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.