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
Well done!
You have completed Design and Development!
You have completed Design and Development!
Preview
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