[Catalyst] Catalyst::Plugin::Prototype: current state?

[Charlie Garrison]

Good evening,

On 22/03/10 at 4:41 AM -0700, Ovid 
<publiustemp-catalyst at yahoo.com> wrote:

>I can't answer these questions. I can only refer you to the rt queue discussion:
>
>https://rt.cpan.org/Ticket/Display.html?id=55742

Thanks, that answered some things, but also just made others 
even more confusing.

Your comment:

>>This is because the author made it clear that authz was not a design
>>concern and the internal URLs vary widely.  Rather than risk opening up
>>a hole to the database, separating this is much safer.

But the author says in the RT ticket:

>Having said that, you should be able to match on the AutoCRUD paths
>within your custom ACL role because they are quite predictable:
>
>/autocrud/* - obviously just your admins
>/autocrud/<db-name>/<table> will be the page for any table

So, while the URLs may vary widely, they are "quite predictable".

Maybe this discussion went off track about being able to specify 
different authz for different portions of AutoCRUD. I'm happy 
with a simple 'any admin can access the whole db' approach. In 
which case the ACL for /autocrud should be sufficient. Or am I 
missing something?

In that ticket the AutoCRUD author also states:

>This has more to do with the philosophy of AutoCRUD. It's meant as a
>tool for the application developer more than the end user, so I have
>never focused on authZ.

And that sort of makes sense, but who is the end-user? Is it my 
$customer, or is it their users of the site? For me, the 
end-user is my $customer and I want to give them full access to 
the database. And AutoCRUD seems like a simple way to achieve 
that. For the app developer, AutoCRUD seems like a toy; I need 
much better/direct db access than is available via AutoCRUD.

So, for the developer, AutoCRUD is a weak tool, and for the 
end-user there is no 'proper' support for authz. There seems to 
be a big gap. Anyway, for now I'm going with the comment 
"AutoCRUD paths ... are quite predictable", and rely on the ACL 
plugin to give the desired authz.

>I didn't see creating a separate app and securing it at the 
>server level as being a big deal (for me, your mileage may vary).

Between the different devs (& even some developers), the test 
server, production server, etc. it's not trivial to simply "add 
another app". Of course it's doable, but I'd prefer to spend my 
efforts on app development than helping designers 
install/configure a second app.

So, thanks for bringing up this issue. It has made me aware of 
some limitations that I hadn't looked at before.

And if anyone thinks that using the Auth::ACL plugin for 
protecting direct db access (eg. /autocrud) is a bad idea, 
please share your thoughts.

Thanks,
Charlie

-- 
    Ꮚ Charlie Garrison ♊ <garrison at zeta.org.au>
    〠 PO Box 141, Windsor, NSW 2756, Australia

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt