Hi, chillu wrote:
> I'm currently implementing a multiuser-system (rss-reader) in cakephp - > and i'm trying to figure out a safe and reusable permission-control. > i've looked at ACL, rdAuth, usermgmt and oceancms, but they all seem to > work only on a per-function base. e.g. "if the user is in group > 'admin', allow access to '/users/edit'". I had a similar problem when I had to implement some "growing archive" blog-type application for our students work. I've settled for dbACL, as that seemed to be the most flexible solution - and I still hope, that it'll get easier to use with upcoming releases of CakePHP. Actually the ACL doesn't restrict you to simple authorization schemes. It doesn't relate to controller functions, but to model permissions - in fact the "create", "read", "update" and "delete" permissions usually describe, what the user (or ARO) can do with that database entry. > due to the multiuser-character of my system, i need a more granular > setting, something like "if the user owns this record, allow > '/users/edit'". Yes, I had the same problem. My first approach was to make an additional check with the model to see if the owner matches the logged in user (as every item belongs to a user). But then I thought that this mixture of ACL and other database checks would be more complicated, when the app evolves. > optimally this would be possible withouth any > function-specific checks - maily because i don't want to clutter my > controller-code (don't repeat yourself) and think permission-control is > more secure on a global (non-function) level. I put my ACL checking into the app_controller, but I still have to query that from every controller function, as I need to manually specify the affected ACO and method. For example, I have a detailed view of an item. In this Item::detail() function I first check if the user is allowed to read that entry. If that function returns FALSE, it also sets the next flash to "you don't have permissions to view xy" and redirects (via history component) to the previous page. If access was granted, it displays the detailed view. Actually ther'es another ACL request to determine if "edit/delete"-links should show up - but this is just an additional service, as the Item::delete() and Item::edit() function also look for the ACL when they're called. > ruby on rails seems to have found a nice solution with the "model > security" module, by combining the beforeFilter() with custom > functions: > http://perens.com/FreeSoftware/ModelSecurity/Tutorial.html Yes. I really like the RoR approach on that, but unfortunately I have to live with PHP on these servers. But you can get very granular results with (db)ACL. I have a structure like this: AROs: everybody users admins user.1 project a user.2 user.3 project b ... and ACOs: users user.1 user.2 user.3 ... projects items item.1 item.2 ... These names are aliases for AROs and ACOs, and with them you can combine them with your models. I also check the session, if the user did login and set the currently active ARO in the session (that would be "everybody", if no one was logged in). You can set the permissions for the AROs to certain ACOs with the methods of the Acl component, and usually you just need to map the "groups/parent ARO & ACO". In my app, I allow the "admins" to to everything and the "users" to create new items. "Everybody" can read items. Everything else is forbidden by default. So now when a user creates an item, I also create a new ACO with the models' ACO as a parent and set up a new rule in the "aros_acos" table to allow this user everything for this item (so now only he or the admin can edit and delete it). It's similar for the users, except that "everybody" is not even allowed to read their data. Every user has access to it's own user-ACO to allow password change or new eMail addresses. This setup allows to set permissions on a project base, so if a term is over, I can prevent the members of project.a to create any new items while still being able to edit their own. If I don't want them to do anything with their uploaded items, I could delete their item's ACO or simply remove the "edit" and "delete" permissions. > am i missing some existing (or obvious) other solutions here? Unfortunately the setup described above seems quite complicated. And there are still some assumptions on permission in it, which are not covered by any ACL rule. For example if there's an item that I don't want everybody to see, it would still show up in a listing from the Item::index() function, as I just check if the logged in user is allowed to see the ACO "items" - without checking for each single item for its permissions. Right now there are already a lot of database queries for the dbACL stuff, it would be worse if I queried each result item for ACL again. And you are not limited to ACLs for your database rows, you can set up any ACO structure you want. The ties between ACL and model are not very strong, it's easy to get away without that (you can call the Alias anything you want, it doesn't have to be a "model.id"). But you have to set it all up manually then. Or short: it is possible to create a complex permissions model with the built-in ACL. But I'd really like to see that more integrated with the models (and IMHO that's where ACL are supposed to be). The RoR approach seems to be an interesting direction, especially as it's still an optional but well integrated component. Regards, Dominik. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~----------~----~----~----~------~----~------~--~---
