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: 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 upYou need to sign up for Treehouse in order to set up Workspace
Sign up