Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
How to Restrict Access7:13 with Jim Hoskins
[?music?] 0:00 [Master Class: Designer and Developer Workflow: Restricting Access] 0:02 [Jim Hoskins] So now we've associated users with jobs and we can easily see 0:05 how we could display which user is associated with a job within our view. 0:09 The next step is we want to make it so that only people who are logged in 0:14 can create a job, and when they go ahead and create that job, we want to make sure 0:18 that we associate the user who is signed in with the new job that they've created. 0:22 That way, later on, we can always check to make sure 0:27 A. That there's a user associated with a job, 0:30 and B. When somebody tries to edit a job, we can make sure that they're authorized to do so 0:33 by checking that the user associated with that job is the user trying to edit it. 0:37 So the way we're going to do this is by modifying the controller 0:42 to make sure that jobs/new and jobs create method 0:46 are only accessible by people who are currently logged in, 0:51 so if we were to type in job/new, 0:55 right now, I'm signed out and we can go to Job Title and we can go ahead and fill in all this 0:57 and create a new job, which is not what we want at all. 1:02 So let's go and check out our controllers. 1:07 I'm going to go ahead and clean a little bit of this up. 1:10 I don't need to be looking at that. 1:13 And what we are going to be focusing on is the jobs controller, 1:16 and this is our standard restful controller. 1:20 We have index, show, new, edit, create, update, and destroy. 1:23 To go through each of these methods and think about how we are logically going to worry about 1:29 the authorization, the index is always going to be available to everybody. 1:33 We're always going to show all the jobs in the database 1:38 and we're always going to be allowing anybody to see a specific job, 1:43 so show is also going to be publicly available. 1:46 The new method which shows the form should only be visible to people who are signed in, 1:50 so that way, if you're not signed in, you can't see the new form 1:55 and the new form should only be visible to people who are logged in. 1:58 And similarly, the create method, which actually does the job of creating it 2:01 should only be accessible to people who are logged in. 2:05 Simply protecting the new form isn't enough because 2:09 somebody could easily enough just post directly to create 2:12 and if we're not checking there, we're not doing an effective job protecting our application. 2:15 The edit and update methods are slightly more complex; 2:19 not only do we want to make sure somebody is logged in, 2:22 but we also want to ensure that the person who is logged in 2:25 is the person who is associated with that job 2:29 and destroy has the same authorization requirements as edit and update. 2:33 We need to make sure that the job is the job associated with the current user. 2:37 So in order to make sure that the new and create are only accessible 2:42 when somebody's user or current user is defined, 2:45 we're going to use a feature in Rails called filters. 2:48 And basically, what they are is we're going to define a method 2:50 and we're actually going to define it in the application controller. 2:53 That way, we can use this everywhere. 2:56 We'll specify at the top of our jobs controller that this new method should be called before 2:59 any time we request new or create. 3:05 And if this method returns false, then Rails will not allow 3:07 our method to actually execute and allows us to protect our method 3:11 based on the return value of that method. 3:16 So I'm going to open up applicationController 3:20 and this is where we're going to write our method that will determine 3:23 whether or not we're logged in. 3:26 So I'm going to call this method require_current_user. 3:28 We'll just do def require_current_user. 3:32 And basically, all I want to do is check that there is a current user, 3:36 and if there isn't, we'll go ahead and put up an error message 3:41 and redirect to the homepage, for instance, and show that error message. 3:46 Now, by redirecting from within a before filter, 3:51 we actually stop the rest of the requests from happening 3:54 so we don't have to worry about things in our actual actions executing after this 3:57 after we redirected somebody. 4:01 So as long as there's a redirect_to call inside of our before filter, 4:03 it is enough to stop the request from happening 4:07 and act as a defense or barrier against unwanted requests. 4:10 So to simply do that, we'll just say unless current_user. 4:15 We will redirect_to root_path 4:22 and we will go ahead and put a flash message 4:28 for [error] 4:32 and say flash[:error] = "You must be logged in." 4:35 So now that we have a controller method called require_current_user, 4:41 we can use this as a before filter. 4:45 So how do we do that? 4:47 We'll open up the jobs controller 4:49 and we will use the before_filter method 4:51 and this will take a symbol that is the name of our method, 4:58 which was require_current_user. 5:00 So let's see where this gets us. 5:06 So if I were to refresh, 5:11 and we jumped into a redirect loop and that's because we're requiring the current user 5:13 for any method inside of our jobs controller, 5:18 including the index action, which is the homepage that we're trying to redirect to. 5:21 So in this case, we got redirected to the homepage 5:26 which also requires a current user which redirects to the homepage, 5:29 so on and so forth, 5:32 and that's obviously not good. 5:34 But fortunately, we also don't want to actually require a current user on the homepage, 5:36 so we need to change our before filter. 5:41 Besides just taking a method, before filter can take options. 5:43 For instance, the option except, and this will take a list of methods 5:46 that we do not want to apply this before filter to. 5:51 So for instance, we don't want to require a user for index: 5:55 :require_current_user, :except => [:index, :show] 5:59 nor the show page. 6:00 Alternatively, we could have used the only option 6:03 and specified which methods should have the before filter, 6:06 but in this case, since there are fewer methods that are the exception, 6:10 except is a better option here. 6:13 So if we save this and refresh, 6:15 now we're able to access Easy Jobs! here 6:18 and that's because we are no longer requiring a current user, 6:21 but if I were to click Edit here, for instance, 6:24 we're getting redirected back to home. 6:27 Now, it doesn't look like our flash error is showing up in our layout, 6:29 so let's take a look at that and see if we can't just get it in there real quick. 6:33 So that's going to be in the app/views/layouts application.html.haml. 6:37 We have a flash notice, but we don't have one for error, 6:47 so I'm just going to copy and paste, change this to error, 6:50 and I'll allow Nick to add the appropriate styling to differentiate between errors and notice. 6:53 So if I refresh, and let's click Edit here, 7:02 we now get "You must be logged in," and I'm sure Nick will style this 7:06 to make this very visible so you can see that there is an error. 7:09
You need to sign up for Treehouse in order to download course files.Sign up