I'm using TG2 authorize, but I understand that the API is the same as that for identity, so I've been looking at those docs and the relevant chapters in the TurboGears book.
I'm working on a proof of concept for a social networking site that is intended to be conducive to emergent behavior. Users and groups are functionally equivalent and parent/child relationships are defined functionally in terms of permissions, but the labels for the relationship and the permissions are intended to be customizable in the database. I expect to take a few hits with this - performance, code readability and development time - but it's part of the concept I'm trying to proof. My questions are about implementation... I want to have a common set of permissions that apply to all entities and map them in the database to local names for display purposes. How do I handle permissions so that if someone is book-cooker for the Bloods and assassin for the Crips, he doesn't automatically become authorized to cook the books for the Crips and assassinate for the Bloods? To use a decorator, I would need to be able to map the required permission from the URL by name string, right? Which is easier to implement - the writing-your-own-predicates identity recipe or a custom authorize decorator like authorize.has_permission_set(perm4group) where perm4group is a tuple that contains the permission required and the domain to which that permission applies? (I'm willing to seed the value of the tuple in the lookup method of the calling controller, but I'd prefer to avoid creating systems names like blood_books, crip_books, etc.) If the custom decorator is the more difficult approach, are there other applications under development that would make the additional effort worthwhile? I want to merge the user and group tables to provide a common pool of ids and enable someone to assign a group as a member of a group so that for all X is a member of Y all members of X have X permissions on Y. There are security implications to track for the users, so this needs to be implemented with care. I was thinking that assigning a given parent group at user creation could be a way of tracking whether the entity is a user or a group, but I'm having difficulty thinking of a clean way to implement the recursion when assigning permissions. There will be situations where a user may inherit permission levels from different sources. The Linux guy in me wants to enable the user to determine which set of permissions he is using by the path he uses to access the resource while the "social entrepreneur" wants to be sure that the user doesn't face an unnecessary obstacle by forcing the user into one method when he has the necessary credentials in the system. Ease of implementation will be the tie-breaker. What are my options and how do I local my points of maintenance for these models? Last, any ideas about handling circular references? Is there a cheaper way to implement circular reference control than fork on test? Eventually, I'll need to look at performance issues like caching identity so that complex identity objects don't slow down page access unnecessarily but still get flushed when there is a change in permissions, but that's beyond the scope of the proof of concept project. (At least something is.) Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
