Hacking Restful Authentication
June 08, 2010
As I mentioned, I’ve used Restful Authentication to add login functionality to several Rails applications over the last four years. While newer methods for authentication have come along, you may have a legacy application still using Restful Authentication, and swapping out your login system may be more trouble than a whole rewrite. However, if you want to stick with your existing code, and add a few features to extend the usefulness of Restful Authentication, read on. I’ll be making the following changes:
- Add fields for users’ names and a boolean field to mark some users as administrators
- Add authorization settings
- Add methods to allow authorized users to edit user accounts
This assumes you’ve got an application up and running and are already using Restful Authentication for a login system.
First, create a migration to add the new fields to the users table (
script/generate migration add_name_and_is_admin_to_users):
Next up are a couple of changes required to the User model (
app/models/users.rb). I’ve omitted some of the code generated by the Restful Authentication gem to focus on the changes, but the key thing to be aware of here is that using an authorization system (Declarative Authorization, CanCan, RESTful_ACL, etc.) makes it much easier to make sure only users with appropriate permissions may edit accounts. RESTful_ACL, used here, expects these settings to be made in the model, while other mechanisms have separate configuration files to store authorization rules. I’ll be covering authorization more in-depth in the next week or two, but basically what’s going on here is:
- Admins can view an index (listing) of users
- New accounts can be created by guests (not logged in) or admins, but not non-admins
- An account may be edited by the account holder or an admin
- An account may not be destroyed by anyone (just for sake of simplicity here; you could change this to allow people to delete their own accounts)
- An account can be viewed (via a
show method) by the account holder or an admin
You’ll also need to make sure any new fields you’ve included in the migration above are listed among the model’s
attr_accessible values (note in the comments that in some cases you might not want to make values accessible, but that’s a topic better covered elsewhere).
Next up is the controller. This should be pretty straightforward–I’m using two
before_filter calls to first check for login on all methods except
create, then assuming that passes I’m using RESTful_ACL’s
has_permission? to make sure the current user is allowed to access the method. The only other thing of note is in
update. Since I’m giving site administrators the ability to add and edit accounts, I don’t want to log administrators in as the new account (whereas I would log in a new user with his new account).
show are pretty straightforward, like they’d be in any RESTful controller/view combo, so I’m not going to detail them.
To correspond with the controller, the views need some updating. I’m showing one view here–a partial for the form, for use in the
edit view templates. Mine’s written in Haml, but if you prefer Erb you should be able to figure it out.
I’ll let you figure out the rest of the views–they are straightforward.
Finally, add RESTful routes for the User model:
That’s it! Your Users scaffold now allows users to edit their accounts and administrators to add or edit any account. If you’re still using Restful Authentication in your app, give it a try and let me know how it works for you. If you’ve got suggestions for how to improve this code please let me know. If you think it would be helpful, I’ll try to put together a quick demo app with these settings and post it to GitHub sometime this week.
blog comments powered by