[rspec-users] [rails] An authorization question

[James Byrne]

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 
this subject.

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 
desired action.

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/.