[Dbix-class] AuthN/AuthZ at the ORM Level?

[Bill Moseley]

On Fri, Apr 9, 2010 at 10:08 AM, Jeff Albert <jralbert at uvic.ca> wrote:

>  So, like many folks, I=92m writing an application that relies on
> DBIx::Class as its ORM, which will be accessible through a web application
> but also from other clients (a command line client, for example). As a
> matter of best practice, should I attempt to implement authentication and
> authorization in DBIC, so that all my clients are automatically made to
> endure  authN/authZ, no matter their implementation; or should I force all
> interaction with the application to go through the web app (ie, command-l=
ine
> client just makes HTTP calls) and centralize my authN/authZ there?
>

Is this a DBIx::Class question or a more general application design
question?

I'm not sure there's a "right" approach -- the layers of the app often get a
bit fuzzy.   Depends a lot on the structure of the application -- i.e. do
you only care that someone is "logged in" or does every object in the model
have an "owner" so that, say, every SQL query must be joined with a
user-rights table?

I used to add much of the access control to the model.  That meant the model
often had methods where I passed in a user.  So, from within a Catalyst app:

    $foo =3D $c->model( 'App::Foo' )->get_foo( $id, $current_actor );

And in one case an app was really user-centric so the User class had an
explosion of delegation methods:

   $foo =3D $current_actor->get_foo( $id );  # Get specified foo if use has
read access to $id

So, cron jobs would load up the model, get a user object and then do its
work.

(I also have used ACCEPT_CONTEXT as a way to provide the current use to the
model.)

More recently, though, I've been using more of a web-services type approach.
 The model code is still very separate from web app (e.g. Catalyst), but it
simplifies things a bit by demanding that all interaction with the
application is via the web.  The cron jobs don't have to run on a server
where the application is installed, there's an existing auth framework,
there's consistent logging, standardized request and response format, etc.
Basically, scripts use the application's API to do all their work.


I appreciate any and all insight you can provide!
>
Well Jeff, I'm not sure how insightful my response is, but I suppose it
looks more insightful than not receiving any response at all.



-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20100411/2c0=
bc9ed/attachment.htm