Rails%203%20In%20Action

Restricting read access
you may have a large number of projects and want to assign a user to only one of
them. Whitelist authorization involves fewer steps in restricting a user to one project.
A good way to think about whitelist authorization is as the kind of list a security
guard would have at an event. If you’re not on the list, you don’t get in. A blacklist
comparison would be if the security guard had a list of people who weren’t allowed in.
This chapter guides you through restricting access to the CRUD operations of
TicketsController one by one, starting with reading and then moving into creating,
updating, and deleting. Any time users want to perform one of these actions, they
must be granted permission to do so, or added to “the list.”
During this process, you’ll see another gem called CanCan, which provides some
methods for your controllers and views that help you check the current user’s permission
to perform a specific action.
You first set up permissions through the Cucumber features, and once you’re done
with restricting the actions in your controller, you’ll generate functionality in the
backend to allow administrators of the application to assign permissions to users.
8.1 Restricting read access
A time comes in every ticket-tracking application’s life when it’s necessary to restrict
which users can see which projects. For example, you could be operating in a consultancy
where some people are working on one application, and others are working on
another. You want the admins of the application to be able to customize which projects
each user can see.
First, you create a model called Permission that tracks which users have which permissions
for which actions. Before you create that model, you must update one of
your Viewing Projects features to make sure only users who have permission to view a
project are able to do so.
Add a background and change the scenario in this feature to set up a user with the
correct permissions, and then make the user visit that project, changing the code in
the scenario in this feature to what is shown in the following listing.
Listing 8.1 features/viewing_projects.feature
Background:
Given there are the following users:
| email | password |
| user@ticketee.com | password |
And I am signed in as them
And there is a project called "TextMate 2"
And "user@ticketee.com" can view the "TextMate 2" project
Scenario: Listing all projects
And I am on the homepage
When I follow "TextMate 2"
Then I should be on the project page for "TextMate 2"
You’ve effectively rewritten a large portion of this feature, which is common practice
when implementing such large changes.
B
165
Let user
view project