In part one of this series on the RESTful_ACL gem, I walked through the steps required to prepare an app to use this handy, albeit overshadowed, mechanism for adding authorization to a Rails application. Now let’s dive into the actual ACL settings themselves. In the interest of simplicity and familiarity, we’ll go with a basic blogging app with categories, posts, and comments. Let’s say that admins can create and edit categories, regular users can write posts and edit posts they’ve written. In this part I’ll cover categories and posts; we’ll use some more advanced features to protect our comments in a later tutorial.
Behind the scenes, I’ve set up a Rails 2.3.8 application with an authentication system installed. The important thing to know here is that your authentication session information must be named current_user
, which has pretty much become practice in every authentication mechanism I’ve seen for Rails in the last couple of years. I’ve also added a boolean is_admin
to my User model and run the generated migration.
First, let’s create the category and post scaffolds (see my post on using Nifty Generators to create Rails scaffolds if you need a primer):
Run the migrations, then open the two new model files. Let’s start with the Category model, which only users where is_admin
is true
may manipulate. Its ACL settings are thus pretty simple:
For each of the five methods in the above model, returning true
will allow the user to access the action in question. Otherwise they’ll get redirected to the denied
path we set up in Part 1 of this tutorial, but first we need to tell the controller to refer to the ACL settings we just created:
Two things going on here: The first before_filter
checks for current_user
(in this case, I’m using Restful Authentication because it’s easy; other authentication mechanisms use before_filter
as well but call different methods—consult their documentation). The second filter tells the controller that this model has ACLs to check. Assuming both of these filters return true
then the requested action will process. Otherwise the user will be redirected to the login path (because :login_required
returned false) or the denied path (because :has_permission?
) returned false.
Let’s clean up a couple of views real quick. In our index view, we only want the links to each object’s Edit and Destroy options, and the New Category form, to be visible if the user has the appropriate permission (that is, is logged in and is an administrator).
There are two things doing the work here—RESTful_ACL’s allowed?
helper is checking the ACL, but only if Restful Authentication’s logged_in?
helper returns true. This two-level setup is necessary because the :index
action doesn’t require login, so some users (guests) may not be logged in.
You can also apply these helpers to show.html.haml
to hide the Edit and Destroy links from non-administrators.
Now let’s move on to the Post model:
The controller and views for the Post scaffold will be set up in the same fashion as they were for Categories.
We’re off to a good start. Our application now protects two models from unauthorized access. Next time I’ll add a basic commenting system to my application, and use RESTful_ACL’s logical parent option to extend existing ACLs to a model’s children. As always, please let me know what you think about this article. I appreciate your questions, comments and suggestions.
Ruby on Rails news and tips, and other ideas and surprises from Aaron at Everyday Rails. Delivered to your inbox on no particular set schedule.