Good evening,
On 22/03/10 at 4:41 AM -0700, Ovid
<[email protected]> 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 ♊ <[email protected]>
〠 PO Box 141, Windsor, NSW 2756, Australia
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
