[rspec-users] [rails] An authorization question

Zach Dennis 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
>   begin
>    invoice.get_collection
>   rescue
>     # decide what to do if we can't get collection
>   end
> end
> 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
> exceptional.)
> 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")
>>    user.in_role("admin").invoices
>>  elsif user.has_role?("associate")
>>    user.in_role("associate").invoices
>>  else
>>    raise AccessDenied
>>  end
>> end
>> 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
>> >

Zach Dennis

More information about the rspec-users mailing list