[rspec-users] [rails] An authorization question
zach.dennis at gmail.com
Tue Mar 3 12:06:32 EST 2009
On Tue, Mar 3, 2009 at 11:07 AM, Andrew Premdas <apremdas at gmail.com> wrote:
> I think this discussion has gone backwards a bit. Here is what I think the
> index method in the invoices controller should be like
> def index
> # decide what to do if we can't get collection
> Now clearly this needs some work to get it to work ...
> 1) What is 'invoice'
> Rails by default ties 'invoice' to a class in app/model. Usually this
> ActiveRecord model class, but it doesn't have to be. We can always put
> another layer inbetween (e.g. Presenter) if it makes our code simpler
Presenters are for presentation logic, not for authorization concerns.
> 2) Authentication parameters
> Clearly these need to be passed through to get_collection. This can be done
> by parameters or by making the authentication available in a wider context.
Authentication isn't the issue here, authorization is.
> 3) Exceptions
> We need an exception hierarchy. NotAuthorised, NotFound etc.
> All the controller should do is get the collection and deal with exceptions
> if the collection is not available. (n.b. the collection being empty is not
> Rails historically has corrupted (compromised, polluted ...) MVC by allowing
> concerns of how we get the collection to be included in the controller.
> RESTful design has highlighted the problems with this and now we end up with
> this situation where things like authentication and authorisation don't
> really have an obvious place.
It is up to the controllers to know how-to ask for something, it
should not know how the internals of that request work. For a
controller to know what role can access a particular resource is
completely aligned with a layered architecture, keeping application
concerns in the right layer, and domain logic in another layer.
> These things - authentication, authorisation and the exception handling (for
> the resource) - are services which all resources need access to. They need
> to be seperated and applied in a cross-cutting manner. Perhaps we could do
> things more elegantly with an Aspect Orientated solution.
Is some cases yes, but I fail to see where it benefits or adds more
value then concretely identifying a role that has particular behavior.
> 2009/3/2 Zach Dennis <zach.dennis at gmail.com>
>> Forgot to mention what we did do. We ended up with the following...
>> def index
>> if user.has_role?("admin")
>> elsif user.has_role?("associate")
>> raise AccessDenied
>> To us, the change here is subtle, but important. The controller is
>> allowed to ask for invoices from each role, but is not allowed to know
>> how find the invoices, that's the behaviour of the role.
>> > --
>> > - Show quoted text -
>> > Zach Dennis
>> > http://www.continuousthinking.com
>> > http://www.mutuallyhuman.com
More information about the rspec-users