Hi Jeremy, The easiest solution is to name your roles with the resource they apply to. Say you have resources r1, r2, and r3 you could name your roles:
r1-edit r2-edit r3-edit r1-write r2-write etc As long as you don't use ``-`` characters elsewhere in the role name this works fine. You then just test for the role ``r1-edit``. The alternative is to write your own custom permissions and your own custom data store. This works fine too but is a lot more work and actually amounts to the same thing anyway. Incidentally, very early versions of AuthKit supported this functionality but I dropped it because the same thing was so easily implemented by just using the naming convention described above. Hope that helps, James Original Message: ----------------- From: Jeremy Burton [EMAIL PROTECTED] Date: Sun, 15 Jun 2008 13:00:27 -0700 To: pylons-discuss@googlegroups.com Subject: "Preferred" approach to extend Authkit to resource level access-control The architecture of Authkit (and the examples/tutorial) seem to assume that users have access-control/permissions at the application-wide level. The application I am developing requires access-control/permissions at the per resource level. i.e. each user has various permissions (read, write, edit, delete) on an arbitrary number of resources. Do any Authkit experts on this list have a strong view on how to use Authkit in this context? I'd rather not reinvent the wheel. Thanks, JB -------------------------------------------------------------------- mail2web.com - Microsoft® Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
