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/. _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
