Adding authorization to your Rails app with RESTful_ACL, part 2: Basic ACLs
June 21, 2010
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
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.
blog comments powered by