Hey Bill, Thanks for the response! Practically speaking, this is a DBIx::Class question, although I thought I’d start off by asking it at the application architecture level, and drill down from there into the DBIC specifics. I definitely need to be as granular as “user x has permission to do action y on object z”; my initial thought was to override the existing DBIC methods (search, find, update, create, et al), but that feels awfully hack-y, especially when my application layer provides such rich authN/authZ tools already – so lately I’m leaning fairly strongly toward, as you suggest, just enforcing that all access to the application will be through a web-service interface which enforces all the rules in a manner that is functionally opaque to all clients – that way, cron jobs don’t get any special consideration by loading the model classes directly, and as you say , then can be run from anywhere. Your post has helped me confirm my decision to go that route, so it probably qualifies as insightful – thanks!
Cheers, Jeff From: Bill Moseley [mailto:[email protected]] Sent: Sunday, April 11, 2010 8:33 AM To: DBIx::Class user and developer list Subject: Re: [Dbix-class] AuthN/AuthZ at the ORM Level? On Fri, Apr 9, 2010 at 10:08 AM, Jeff Albert <[email protected]<mailto:[email protected]>> wrote: So, like many folks, I’m 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-line 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 = $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 = $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 [email protected]<mailto:[email protected]>
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
