The following elements conform a RBAC permission in django-rbac:
1. The owner: The proprietary of either the object being accessed or the permission rule itself, e.g. a site user or a community administrator. 3. The object: The element being accessed on which the permission is being checked upon, e.g. a profile or photo album. 3. The operation: The action requested, e.g. display, create, delete, show birth date, send message or request friendship. 4. The roles: Define who are the requesting users in relation to the owner or the object, e.g anonymous, friend, family, coworker, or roommate.
This is best explained with a simple example:
* User Fritz wants to see Mr. Natural's profile. Thus, Fritz (subject) requests permission to access (operation) the profile (object) of Mr. Natural (owner).
* Fritz is an 'anonymous' user (role), a role that everybody holds initially in the system. As Fritz and Mr. Natural are friends, the role 'friend' is appended to the roles. So we have a role list containing 'anonymous' and 'friend'.
* The privacy framework performs its magic to pull an answer: has Fritz permission to access this profile?
o For the 'anonymous' role, the system denies the access.
o For the 'friend' role the access is granted, as Mr. Natural had set access only to friends to his profile.
* Access is granted, so Fritz can go ahead and view all the stuff.
Permissions can be assigned to either a single object ("per-object permission" category, also known as "granular permissions" or "row level permissions") like in the example above, or to all objects of the same model class. For this reason, django-rbac implements two classes respectively: RBACPermission and RBACGenericPermission.
Product's homepage
Requirements:
· Django
· Python
Find us on Google+
