On Tue, Mar 3, 2009 at 11:07 AM, Andrew Premdas <aprem...@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.den...@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
http://www.continuousthinking.com
http://www.mutuallyhuman.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
