[Catalyst] Authorization ACL: future plans?
Matt S Trout
dbix-class at trout.me.uk
Thu Jun 12 15:00:38 BST 2008
On Wed, Jun 11, 2008 at 07:52:27PM +0100, ivorw wrote:
> Jonathan, thank you for a most thought provoking reply. I couldn't work
> out whether you were playing devil's advocate, or if you completely
> believe that my generic approach is doomed to failure.
He's half right.
Making something completely generic will be impossible - or you'll end up
implementing what amounts to a data-driven programming language, and it'll
be as hard work to configure usefully as, say, windows authz.
Making something that provides a nice structure for building authorization
systems is very possible; this shouldn't be a Catalyst::Model, it should
be a general CPAN module.
Then you define a set of APIs that different components in the system talk,
and your app's requirements become one set of implementations of those APIs.
Then you build a Catalyst::Whatever that acts as an adaptor from Catalyst to
your authz model.
There's no need necessarily to do all this up front, but you should bear in
mind that authorization structures -do- vary wildly from app to app so
however you do it some consumers of it will need to replace one or more of
Consider the way Plugin::Authentication separates realms, credentials and
stores as a reasonable example of the concept. The guts of Authorization::ACL
may be inspiration as a way to integrate this security into your controller
paths; personally I think I'd be more interested in being able to integrate
it into my model - so I can require a certain permission to call $obj->update
on a DBIC row or whatever.
Might be interesting to start a thread on the DBIC list about model level
security if you were so inclined.
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
More information about the Catalyst