I would like to learn to implement role-based access control on my growing apps. In former days, I would create a db field for users with a string like 0000101111101100011111, where each place holder was given a 'role'. Then in my app I would see whether or not the account had that permission switched on (in other words, character #5 means "isInstructor") and grant an action accordingly.
As the app grows, however, that becomes cumbersome.... Not very DRY either.
I've notices in larger professional apps that developers use separate tables.... a users table, a roles table, and a permissions table. This makes more sense.
What is the best practice in Rails??
Something like this?
http://wiki.rubyonrails.or
Thank you!
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
http://code.google.com/p/r
I like this one because it's cleaner in the implementation.
Certainly, any implementation that can use before_filter to restrict specific actions will be way cleaner than something like below.
But I think dberner9's solution sounds really cool, too!
You may want to look into caching queries, too, because the user's roles/permissions probably need to be looked up on every page view and probably don't change very often.
Business Accounts
Answer for Membership
by: dberner9Posted on 2008-02-20 at 06:20:39ID: 20937926
In the app I'm working on now, permissions is a big aspect.
We have users, roles, clients, templates, and permissions.
A role consists of an ActiveRecord class and a method/wildcard on that class. Literally, the role of calling this method on an object of this class.
A permission is a role, plus a client, plus an allow/deny bit. "Do I have this role under this client?"
A template is a group of permissions that can be assigned out to any users. This is simply a convenience that cuts down on configuration time.
A user has many templates and permissions. Specific permissions override template permissions.
And, of course, the default policy is denial. If a permission is not found, it is assumed to be off.
We alias all ActiveRecord calls so that the system knows the current user has permissions to even call the current function on a database object within the scope of the client that owns that object. For speed, we cache the results of these lookups in the local file system.
We specify the roles necessary to perform EVERY web action, and even have a global helper method that protects hyperlink rendering so that users aren't even given the option to try and do something they cannot do.
We also have a superuser mode that is given as a closure, in order to do things like log a user in or perform local cron tasks.
This very effectively scopes our permissions to specific actions within the specific contexts of our various clients.
I don't know if this is a "best practice" but it's what is needed by us due to the high sensitivity of our database content and the need for very granular control over user access.