[LRUG] Chat Digest, Vol 30, Issue 21

[Sam Livingston-Gray]

Greetings, Andy-

Whatever its other shortcomings, I think Hobo got authorization almost
exactly right.  Models have a set of
/(editable|viewable|updatable|creatable)_by\?/ methods which take a
User object, and if those are missing, it falls back to a
/can_(edit|view|update|create)\?/ method on User.

Under this scheme, the controller knows who the current user is
(that's its job, after all -- to manage state between HTTP requests),
and if the views need to change based on permissions, they can ask the
controller for current user, then ask the model whether that user is
authorized to update it.  The model, meanwhile, knows that it may
allow one instance of the User class to perform an action while
denying a different instance, but it doesn't have to care where that
user instance came from, or why it's asking (again, that's a
controller's job).

While this does lead to some repetition in your view code (with views
asking each model "would this be okay?"), I don't think that
repetition is at all avoidable.  However, the verbosity is minimized
[and can be factored into a helper called crud_links_for(object)], and
more importantly, the responsibility of confirming who's authorized
for which action rests solely in the model.

Hope this helps,
-Sam


> Date: Mon, 28 Jul 2008 10:46:30 +0100
> From: Andrew Stewart <boss at airbladesoftware.com>
> Subject: [LRUG] [Off-Topic] Authorisation
>
> Hola El Rug,
>
> In my current Rails project I have a screen that lists all the people
> who can log in.  A person may update their own details, and an
> administrator may update anyone's details.
>
> So in the view I need to use that logic to determine whether or not to
> show an edit link by each person.  In the controller, I use that logic
> to determine whether or not the current person (i.e. the person using
> the app) can execute the edit and update actions (because they may
> have typed the URL directly).
>
> Right now I have repeat the logic in the view and the controller.
> However I think the authorisation logic would be better off in the
> model, perhaps with an is_editable_by?(person) method on the Person
> object.  But the model doesn't know anything about the current person
> (which is why auditing plugins resort to hijacking Rails' caching
> mechanism to track who does what to the models), so I can't see how to
> enforce the authorisation in the model layer.
>
> In a nutshell, I think that the authorisation logic should live in the
> model layer, and the view and the controller should query the model to
> find out what is allowed.  However the model layer can't enforce the
> rules; only the controller can.
>
> Have I missed anything?  Is there a better way to do this?  I'd
> appreciate your thoughts.
>
> Regards,
>
> Andy Stewart