Heads up! To view this whole video, sign in with your Courses Plus account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
DESCRIPTION TK
This video doesn't have any notes.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
[?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
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up