How to Protect from Modification

[?music?] 0:00 [Master Class: Designer and Developer Workflow: Protecting Job Modification] 0:02 [Jim Hoskins] So now we have the ability to log in and log out, 0:05 and when we're logged in, we're able to create a new job and when we're logged out, we're not. 0:08 And when we create a new job, our currently logged-in user is associated with that job, 0:12 as demonstrated by this new one where I was logged in as Nick when I created it 0:17 and the job is associated with Nick 0:21 while the other ones are associated with the Jim account. 0:23 So now that I'm logged in as Nick, should I be able to edit one of Jim's? 0:26 Probably not, so how do we go about restricting that? 0:31 Well, we can write another before filter, so let's go back to our controller. 0:34 So we use another before filter and what I want to do is call this 0:38 before_filter :require_job_belongs_to_current_user. 0:43 Now, that is a mouthful of a method name, but it really does describe 0:58 what we're going for here. 1:02 And we only want to do this for edit, which is the edit page, 1:06 the update, which is the page that actually handles updating the information 1:09 as well as destroy, which destroys the model. 1:18 So I'm going to actually write 1:22 :require_job_belongs_to_current_user in this controller 1:25 and that's because it's really only focused around the jobs controller, 1:28 not as general as require_current_user. 1:32 So let's just grab that and below all my other methods here, 1:35 go ahead and create a private method 1:39 that we'll call require_job_belongs_to_current_user. 1:44 Now, there's an interesting thing here. 1:47 We actually do need to--from within the before filter--fetch the actual job 1:50 that's being requested for this particular request, 1:56 and we can see how the job is currently being fetched from destroy, update, and edit. 1:58 It's simply being assigned to @job = Job.find(params[:id]) 2:04 and if we look at the other ones, we see the same thing. 2:08 So because our before filter will always be run before edit, update, and destroy, 2:11 we can actually set @job from inside of our before filter, 2:17 so I'm just going to go ahead and pull that. 2:23 We don't need anything in edit anymore 2:26 and we can remove the same line from update 2:29 and from destroy, 2:34 and we'll place it into require_job_belongs_to_current_user. 2:39 Just to see that that had no adverse effect, let's just see if we can load up the edit page 2:42 with this new code layout. 2:46 I have the edit page already loaded, so if I refresh it, 2:48 nothing broke because we just simply moved the fetching from one method 2:51 to another method that happens right before that method. 2:56 So functionally, they pretty much work the same. 2:59 So now that we have @job, we actually want to only succeed 3:02 if the job belongs to the current user. 3:06 Now, one way we could do this is to test job.user_id == current_user.id 3:11 and since this is the last line of our method, 3:26 it will return true if it's true; 3:28 otherwise false, which will stop the page from loading. 3:30 So here, I'm on the Fashion Police Officer, which was actually created by Jim 3:36 and I'm signed in as Nick, so if I refresh, 3:39 so one way we can ensure that the job belongs to the current user 3:42 is to actually scope the Job.find to the user's jobs. 3:46 So instead of actually using our find method on the job class, 3:50 we can do current_user.jobs, and what this will do 3:54 is it will actually apply the find method, but only for the current user's jobs 3:59 or the jobs where the user_id equals the current user's id, and if there is none, 4:04 it will raise an exception for Not Found, which will result in a 404 page. 4:09 And this is fine because we shouldn't be linking to the edit page anyway, 4:13 so a 404 is actually kind of an appropriate error. 4:18 Otherwise, you could modify this logic a little bit to either redirect 4:22 or bring up a different type of error, 4:26 but the 404 as a harsh error seems like it will work just fine for our needs, 4:29 so let's save it out. 4:33 So I'm on the edit page for the Fashion Police Officer, 4:35 which was something that was created by the Jim account, 4:37 and I'm logged in as the Nick account, so if I refresh this page, 4:40 the new rule should take into effect and we should get a Not Found error, 4:42 and we did because we couldn't find a job with the id of 2 where user_id = 2 4:46 and that's how it was scoped to the current user. 4:51 So the same thing would happen if we tried to submit the edit form somehow 4:53 if we were able to get to it, so it looks like we should be pretty safe. 4:56 We shouldn't be able to destroy or edit or update any of the information 4:59 on a record that's not ours. 5:04 But to check, let's go back, and I'm logged in as Nick, which the only job posting 5:07 is Hammock Comfort Specialist, which I can edit and I will update the name of the company 5:12 with some exclamation points and save it out, 5:19 and we are able to successfully save. 5:22 If I sign out and sign in as Jim, 5:28 I can now try to edit Fashion Police Officer, for instance, 5:33 and change this to Senior, 5:36 save it out, and I can. 5:40 If I were to try to edit the Hammock Comfort Specialist, again, we get an error. 5:44 So one of the last things we want to do is we only want to show edit 5:48 if the current user owns the job, so let's go and look in the index, 5:52 and here we see our link to edit and what I want to do is I want to wrap this in 5:58 - if job.user == current_user 6:03 then we will link to edit, so now it's conditional. 6:11 So now I'm signed in as Jim, the Hammock Specialist edit has disappeared 6:15 and we want to definitely do the same thing here on the actual show page, 6:19 which is easy enough to do. 6:22 Just take show here, find our edit page, 6:25 and here we'll do if @job.user == current_user, 6:31 then we'll link to edit and we'll show the little bar there 6:38 and Nick can fix up the markup for that when he gets to this page. 6:42 So we'll save it out, refresh, and I forgot to put a - there. 6:46 Otherwise, it was just interpreted as plain text, and there we go. 6:51 So now we only see the Back button, but if we go to one of ours, 6:55 we can see we have an Edit button, so now, we are restricted 6:59 to only editing the jobs that we have created. 7:03