{
    "info": {
        "author": "Hector Garcia",
        "author_email": "hector@nomadblue.com",
        "bugtrack_url": null,
        "classifiers": [
            "Development Status :: 4 - Beta",
            "Environment :: Web Environment",
            "Framework :: Django",
            "Intended Audience :: Developers",
            "License :: OSI Approved :: BSD License",
            "Operating System :: OS Independent",
            "Programming Language :: Python"
        ],
        "description": "Overview\n========\n\nFirst of all, I would like to show some drawbacks of\nDjango's current permission system:\n\n* Permissions are tied directly to the ``User`` model from\n  ``django.contrib.auth``, so you cannot use any other existing\n  model in your application.\n* The task of mantaining this list of permissions in the current Django system\n  is responsibility of a superuser or some other kind of centralized entity.\n\n* You can certainly assign permissions to ``Group`` model instances, but all\n  users in this group will share the same permissions.\n\n* Last, but not least, until Django v1.2 will come and ticket `#11010`_\n  implemented, the permission system is model-level -- it doesn't allow granular\n  permissions (row-level), which means you can give a user authorization to do\n  something based on all instances of a model class, but not to a\n  single model instance (an object).\n\nMany applications, and specially today's web applications -- which involve\nconcepts as collaboration or content driven by the users -- need the flexibility\nto support delegation of permission granting to objects by other trusted agents.\nA clear example is a social networking site, where the users want to allow or\ndeny access to their profiles or pictures, open or close their different\ncommunication channels like receiving friendship requests or private messages.\ndjango-rbac tries to champion this by introducing some key features from the\nRole-Based Access Control (RBAC_) proposal. In this implementation users\n(subjects) are assigned different roles that, in turn, have (or not) privileges\nover objects. With this permission system, the owner of an object can give\nprivileges to certain roles. For example, a user can grant access to other users\ntrying to read some personal info only if they belong to, at least, one of\nthe roles specified in the permission rule. \n\nI initially developed the first version of this app for a social network, to\ngive its users the ability to control who has privileges upon their profiles,\nphoto albums, personal information, and such. If you are in a similar situation,\nyou'll find that django-rbac suits perfect for your purposes. But, as long as a\ngeneral-purpose access control is being implemented, even if you are building\nany other kind of application which needs this level of permission control,\ndjango-rbac will help you out. I think I have made it enough generic to match a\nwide range of use cases.\n\nI you are interested, you can read the `introduced formal model`_ by\nF. Ferraiolo and D. R. Kuhn.\n\n.. _#11010: http://code.djangoproject.com/ticket/11010\n.. _RBAC: http://csrc.nist.gov/groups/SNS/rbac/\n.. _introduced formal model: http://csrc.nist.gov/groups/SNS/rbac/documents/Role_Based_Access_Control-1992.html\n\nDownload & Installation\n=======================\n\nStable code\n-----------\n\nYou can use your favorite management tool to install (the old and well-known\neasy_install or the better pip::\n\n    easy_install django-rbac\n    pip install django-rbac\n\nOr you can download and install the source code yourself\n(``python setup.py install``) from here::\n\n    http://bitbucket.org/nabucosound/django-rbac/downloads/\n\nLatest Development code\n-----------------------\n\nSource code is hosted in Bitbucket here_.\n\nInstall Mercurial_ if you don't have it yet, and clone the repository::\n\n    hg clone http://bitbucket.org/nabucosound/django-rbac/\n    \nSymlink to the folder called ``rbac`` inside ``django-rbac`` from somewhere\nin your PYTHONPATH -- could be the system-wide ``site-packages`` python folder,\nor the path your virtualenv project is using, if you are using Virtualenv_\n(which I strongly encourage). And if you do and are also using\nVirtualenvwrapper_ then you can easily ``add2virtualenv``.\n\n.. _here: http://bitbucket.org/nabucosound/django-rbac/\n.. _Mercurial: http://www.selenic.com/mercurial/\n.. _Virtualenv: http://pypi.python.org/pypi/virtualenv/\n.. _Virtualenvwrapper: http://www.doughellmann.com/projects/virtualenvwrapper/\n\nDependencies\n============\n\nBe sure you have ``django.contrib.contenttypes`` installed in you project.\n\nOverview\n========\n\nThe following elements conform a RBAC permission in django-rbac:\n\n1. The **owner**: The proprietary of either the object being accessed or the\n   permission rule itself, e.g. a site user or a community administrator.\n\n2. The **object**: The element being accessed on which the permission is being\n   checked upon, e.g. a profile or photo album.\n\n3. The **operation**: The action requested, e.g. display, create, delete, show\n   birth date, send message or request friendship.\n\n4. The **roles**: Define who are the requesting users in relation to the owner\n   or the object, e.g anonymous, friend, family, coworker, or roommate.\n\nThis is best explained with a simple example:\n\n* User *Fritz* wants to see *Mr. Natural's* profile. Thus, *Fritz* (subject)\n  requests permission to access (**operation**) the profile (**object**) of\n  *Mr. Natural* (**owner**).\n* *Fritz* is an 'anonymous' user (**role**), a role that everybody holds\n  initially in the system. As *Fritz* and *Mr. Natural* are friends, the role\n  'friend' is appended to the **roles**. So we have a role list containing\n  'anonymous' and 'friend'.\n* The privacy framework performs its magic to pull an answer: has *Fritz*\n  permission to access this profile?\n\n    - For the 'anonymous' role, the system denies the access.\n    - For the 'friend' role the access is granted, as *Mr. Natural* had set\n      access only to friends to his profile.\n* Access is granted, so *Fritz* can go ahead and view all the stuff.\n\nPermissions can be assigned to either a single object (\"per-object permission\"\ncategory, also known as \"granular permissions\" or \"row level permissions\")\nlike in the example above, or to all objects of the same model class. For this\nreason, django-rbac implements two classes respectively:\n``RBACPermission`` and ``RBACGenericPermission``.\n\nHow it works\n============\n\nAsking for permission in django-rbac is a 2-step process:\n\n1. Get the roles: The user that tries to perform the operation over an object\nor model does so within a context given between him and the owner or the\nobject/model itself. You have to provide a python list of ``RBACRole``\nobjects to the function that will later check authorization.\n2. Call the ``get_permission`` method from one of the two RBAC permission\nobjects (``RBACPermission.objects.get_permission`` or\n``RBACGenericPermission.objects.get_permission``). The method will return\n``True`` or ``False`` if the operation is authorized or not.\n\nYou are totally responsible of executing step 1. The ways that roles can be\nassigned to users are endless, particular to each application or project, so\ndjango-rbac cannot provide any generic method to accomplish this task. Jump to\nthe subsection \"Writing functions to get roles\" in the \"Roles\" section for\nmore information.\n\nOperations\n==========\n\nThe ``RBACOperation`` model defines operations that can be done in the system,\ne.g. 'display_profile', 'send_message', 'request_friendship', or 'show_email'.\nYou can define what you want, just try to stick to a common syntax convention\nand short names for your own sake.\n\nRoles\n=====\n\nOriginally a role is a job function within the context of an organization, but\nit can also be seen like a relationship between the requesting user (subject)\nand the owner. Users trying to perform operations over objects can do so in\nmultiple fashions. For example, someone asks for permission to see, let's say,\na photo album from another user. Such requesting user can be friend or family\nof the album owner, a member of a photography community, or maybe an anonymous\nfolk with a deep interest in other's pics. Thus, 'anonymous', 'friend',\n'community_member' or 'family' would be names of ``RBACRole`` roles that users\ncan belong to.\n\nWriting functions to get roles\n------------------------------\n\nYou need to provide your app some programming logic to know which roles is the\nrequesting user going to play. A common case is the ``request.user`` in a\nDjango view. See this example extracted from the project that comes with the\ndjango-rbac package in the ``example`` folder::\n\n    from rbac.models import RBACRole\n    \n    def get_user_roles(user, target_user):\n        roles = []\n        # These two functions below would validate the relationship\n        # between the two users.\n        # If any exist, append the corresponding role to the roles\n        # list to be returned.\n        if users_are_friends(user, target_user):\n            #Assuming 'friend' role object exists\n            roles.append(RBACRole.objects.get(name='friend'))\n        if users_are_coworkers(user, target_user):\n            #Assuming 'coworker' role object exists\n            roles.append(RBACRole.objects.get(name='coworker'))\n        return roles\n\nPermissions\n===========\n\nOnce you have your operations and roles ready, you can start creating\npermissions. RBAC enables the conditions for the implementaiton of what is\ncalled the *Separation of Duties* (SoD), so tipically applications or projects\nusing django-rbac will set mechanisms to delegate creating new permissions\nto owners. That is, the owner of an object will be who is setting the\npermission level to all the operations that can be done with the object.\nYou are again responsible of providing the user an interface to accomplish\nthis task. Classical social networks, for example, give their users a\n'privacy' page with forms to change different permission settings.\n\nAs mentioned in the beginning of this document, the scope of a permission can\nbe row level (``RBACPermission``) or model class level\n(``RBACGenericPermission``). Both models receive:\n\n* The model instance of the permission owner, e.g. a ``User`` object.\n* An ``RBACOperation`` object for an operation, e.g. 'display_profile'.\n* A list of ``RBACRole`` objects, e.g. 'anonymous', 'friend' and 'coworker'.\n* The object: ``RBACPermission`` receives a model instance (for example, a\n  ``Group`` object), while ``RBACGenericPermission`` receives a class model\n  (for example, a ``Group`` model).\n\nTwo things to keep in mind when planning your permissions:\n\n* django-rbac follows this golden rule: *if a permission doesn't exist, the\n  operation is denied*. This is for convenience, because fewer permission\n  objects need to be created.\n* Try to avoid defining permissions that contain mutually exclusive roles.\n  For example, a permission could have 'friend' and 'anonymous user' into his\n  list of roles. The first allows the permission operation to everybody, while\n  the second restricts an access only to friends, so both are mutually exclusive.",
        "description_content_type": null,
        "docs_url": null,
        "download_url": "http://bitbucket.org/nabucosound/django-rbac/downloads/django-rbac-0.9.tar.gz",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "http://nomadblue.com/projects/django-rbac/",
        "keywords": null,
        "license": "UNKNOWN",
        "maintainer": null,
        "maintainer_email": null,
        "name": "django-rbac",
        "package_url": "https://pypi.org/project/django-rbac/",
        "platform": "UNKNOWN",
        "project_url": "https://pypi.org/project/django-rbac/",
        "project_urls": {
            "Download": "http://bitbucket.org/nabucosound/django-rbac/downloads/django-rbac-0.9.tar.gz",
            "Homepage": "http://nomadblue.com/projects/django-rbac/"
        },
        "release_url": "https://pypi.org/project/django-rbac/0.9/",
        "requires_dist": null,
        "requires_python": null,
        "summary": "Role-based Access Control (RBAC) implementation for management of permissions in Django.",
        "version": "0.9"
    },
    "last_serial": 802925,
    "releases": {
        "0.9": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "5ac52ce2c1a2998c0e8fc823a6b4cd54",
                    "sha256": "ea1434ee9919b308b319476231dced166804d6e0a9357c0956bb38910e08c690"
                },
                "downloads": -1,
                "filename": "django-rbac-0.9.tar.gz",
                "has_sig": false,
                "md5_digest": "5ac52ce2c1a2998c0e8fc823a6b4cd54",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 15117,
                "upload_time": "2010-03-31T20:05:22",
                "url": "https://files.pythonhosted.org/packages/c5/c5/1c7995be9188784690009abcd220c1a35e91be31dbb692267e446ea378c6/django-rbac-0.9.tar.gz"
            }
        ]
    },
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "5ac52ce2c1a2998c0e8fc823a6b4cd54",
                "sha256": "ea1434ee9919b308b319476231dced166804d6e0a9357c0956bb38910e08c690"
            },
            "downloads": -1,
            "filename": "django-rbac-0.9.tar.gz",
            "has_sig": false,
            "md5_digest": "5ac52ce2c1a2998c0e8fc823a6b4cd54",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 15117,
            "upload_time": "2010-03-31T20:05:22",
            "url": "https://files.pythonhosted.org/packages/c5/c5/1c7995be9188784690009abcd220c1a35e91be31dbb692267e446ea378c6/django-rbac-0.9.tar.gz"
        }
    ]
}