http://rails-engines.rubyforge.org/rdoc/user_engine/
From the fiery depths of the README:
UserEngine: Login + Roles
The UserEngine[1] extends the LoginEngine with a very, very simple
implementation of RBAC - role based access control. As well as the
‘User’ object, the UserEngine provides Permission objects, and Role
objects. Each User can have many Roles, and each Role is associated
with many Permissions. A Permission is simple a controller/action
pair. A Role which is associated with some permission has access to
that specific controller/action, i.e. any Role associated with the
Permission object “user/home” will be allowed to call that action.
I’ve tried to keep it very very simple conceptually as well as
implementationally, with as little ‘magic’ as possible whilst still
working as you might expect from that description.
Not the One True RBAC system
I’ll make this point at the beginning, so there can be no doubt - this
is not a full permission system. The UserEngine only controls which
users have the right to hit which controller/action pairs. It will not
control access to data at all, so for instance you cannot use it to
give users the ability to edit only a subset of your data objects
(unless that subset is controlled via a different set of controller
actions).
That said, it’s an example that I hope people will:
a) look at;
b) criticize/patch/enhance it;
c) possibly find helpful as an example of how to approach this
problem (or even how NOT to) when they’re writing their own stuff;
d) possibly even use or customize for their applications if it seems
like a good fit for their needs;
e) all of the above.
It’s not perfect - in fact I would probably call this a release
candidate, although we’ve been using it in our applications for months
- but maybe you can help make it better if you find it useful
yourself. It can doubtless be improved, but please keep your criticism
constructive, and patch-driven if possible…
But I Think Project X/Y/Z Is Better!
(or - Maybe One Day I Won’t Have To Write Another One Of These
Disclaimer Paragraphs)
You could certainly be right, and I’m not going to argue with you. But
please take note: the UserEngine is NOT a challenge to
ModelSecurity[2] (it addresses a different aspect of application
security if you look closely) or ActiveRBAC[3] (it’s goals are far
less wide-reaching).
It is NOT trying to be ‘better’ than any of these, and it looks
forward to happily coexisting with both (and any other mechanisms
people might be brave enough to expose). Just like web frameworks
could be be argued to be in a “mutual cannibalization frenzy” at the
moment, there are plenty of ideas to share around in the space of user
access control.
But talk is cheap; code is better. So here is some code, yo. Check it
fo’ real, h-dawgs[4]. Ahem.
The Leftovers
Please make sure you have the very latest Engines plugin and Login
Engine from SVN while you’re using this. For more information, README
and general docs:
http://rails-engines.rubyforge.org/rdoc/user_engine/
SVN repo:
http://opensvn.csie.org/rails_engines/plugins/user_engine
Issue tracking:
https://opensvn.csie.org/traccgi/rails_engines/trac.cgi
- james
[1] http://rails-engines.rubyforge.org/rdoc/user_engine/
[2] http://perens.com/FreeSoftware/ModelSecurity/
[3] https://rbaconrails.turingstudio.com/trac
[4] The Onion | America's Finest News Source.
