[Catalyst] Authorization ACL: future plans?

[ivorw]

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.

I may get it wrong, but I will learn from the experience. There is no
failure, only feedback. Saying "It can't be done" is a red rag to a bull
with me, and stimulates me to invoke the Perl virtue of hubris.

Comments below:

Jonathan Rockway wrote:
> * On Fri, Jun 06 2008, ivorw wrote:
>   
>> 1. I'd quite like the idea of a generic "resource", that users have
>> access to, rather than just a controller method. The resource could be
>> or correspond to a file on the server's fs, a wiki page, a diary
>> appointment, etc.
>>
>> The resource would have a set of permissions, controlled through the model:
>>  * See   (whether this resource actually appears at all)
>>  * Read (Are the contents of the resource visible/executable?)
>>  * Modify
>>  * Delete
>>  * Grant (who can change the permissions for this resource)
>>     
>
> I don't think a Catalyst plugin is where this sort of code belongs.  It
> belongs in a layer unrelated to Catalyst.  I also don't think this can
> be done generically enough to make it useful.  (Too generic and it won't
> save any time, too specific and you'll be the only user.)
>   
Do you have any evidence for this? Can you point me to someone else's
failed attempt to do it; that would be very much appreciated.

> For something DBIx::Class-specific, look at
> DBIx::Class::Schema::RestrictWithObject.  Basically, you have an object
> that does the access control (per-resultset), and your application never
> sees data that the user isn't allowed to see.  This is the right level
> of generic-ness.
>   
Thank you! I'll look at D::C::S::RWO and work out whether it meets my
needs. I'm now looking at a Catalyst::Model:: module rather than a
plugin, as that is where I now feel this functionality should go.
> Authorization::ACL is completely differnet,BTW.  It's nice for walling
> off part of your application; mainly so you don't have to check
> $c->user_exists for every action that $c->user touches.  But, it doesn't
> try to guess what your application's data means, it just turns part of
> the app off based on some rules you set up.  Again, the right level of
> generic-ness.
>
> What I'm trying to say is that access control and C::P::A::ACL are two
> different things.  Catalyst shouldn't even be in your mind when you are
> designing the access rules and code for your data.
>   
The point is that I'm not designing the access rules. My admin users
(i.e. my clients) are deciding who has access to their data, and I need
to provide flexibility.
>   
>> [snip]
>>
>> By the way in case you are wondering, I am looking to write a CMS that
>> sits on top of Catalyst.
>>     
>
> Write the CMS first, then factor out the access control code.  If you do
> it the other way around, it probably won't turn out the way you want.
> (Nothing is worse than writing a library and then having your
> application that uses it work around it.  Trust me, I've done that.)
>   
Sorry, that won't do. I have some very much simpler needs for access
control than the CMS. I'm going to design the access control layer to
meet the immediate requirements, with the CMS in mind as a future
requirement.

Even if nobody else uses my module, I don't care, as I have multiple
applications for it. Anyway, I've had a reply off-list from someone who
has applications, who is interested in working with me to develop the
modules.

Ivor.