[rspec-users] [rails] An authorization question
lists at ruby-forum.com
Tue Mar 3 10:08:38 EST 2009
Mark Wilden wrote:
> You do consolidate all your _access_ logic in one class, just as you
> might consolidate all your sales tax knowledge in another class. That
> way you have one source of responsibility for that behavior.
> Otherwise, if you added, changed or deleted a role, you'd have to
> change every model.
> This is basically the Mediator pattern. Pluses and minuses, to be sure.
This is not where I am spending my time at the moment, but it is an area
that i am going to confront sooner than later. So, I am interested in
If I understand aright, it is agreed that authorization is best
determined by the user model, either as a full-blown authorization
method wholly contained in the User class or as a call to a subordinate
Authorization class which does the heavy lifting and then returns the
result to the User class. The controllers (and perhaps models) that
require authorization simply call the equivalent to an "authorized?"
method on the current_user passing the context, whether this be a named
role or a control/action pair or a model/attribute pair. The
User.authorized? method simply replies whether this current_user belongs
to the named role or otherwise has the privilege of performing the
If there is an Authorization class then this is where the work is done
(lookups on models or tables as the case may be).
Does this capture the essence?
The question that I have is: If one implements an authorization system
as a model or models then would this best be implemented in the user as
an association rather than as a separate Authorization class?
Posted via http://www.ruby-forum.com/.
More information about the rspec-users