User Engine: Login + Roles


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

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:

SVN repo:

Issue tracking:

  • james




On 11/28/05, Peter M. removed_email_address@domain.invalid wrote:


Rails mailing list


Hi James,

You wrote that the ActiveRBAC component is less wide reaching then your
Engine. What do you mean by this? (I’m just starting to learn about

To bad about having to be so defensive about engines in general. From a
practical viewpoint they are essential for rapid applicaiton



Hi Peter,

Ooos!! HUGE apologies to the ActiveRBAC guys - what i was trying to
say was the opposite, but clearly it didn’t come out that way. Replace
‘less’ with ‘more’ in what I wrote above. Again - huge apologies!

ActiveRBAC, as I understand it, will try to produce an RBAC system
which is more comprehensive than the UserEngine, and I look forward to
its next release. Teh L-userEngine will be teh sux in comparison, I
have no doubt :slight_smile:

  • james (cannot type to save his life)