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: 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