cubicweb-localperms


Namecubicweb-localperms JSON
Version 1.0.0 PyPI version JSON
download
home_pagehttp://www.cubicweb.org/project/cubicweb-localperms
Summaryallow definition of local permissions
upload_time2023-08-11 07:17:50
maintainer
docs_urlNone
authorLOGILAB S.A. (Paris, FRANCE)
requires_python
licenseLGPL
keywords
VCS
bugtrack_url
requirements No requirements were recorded.
Travis-CI No Travis.
coveralls test coverage No coveralls.
            Summary
-------

This cube allows definition of local permissions using a generic
`CWPermission` entity type which you should use in your schema
definition.

A `CWPermission` entity type:

* has a name and a label

* means groups linked to it through the 'require_group' relation have
  the <name> permission on entities linked through the
  'require_permission' object relation.

To speed-up things, a 'has_group_permission' relation is automatically
maintained, so 'P require_group G, U in_group G' is equivalent to 'U
has_group_permission P'.

Client cubes should explicitly add 'X granted_permission CWPermission'
and 'X require_permission CWPermission' for each type that should have
local permission, the first one being explicitly granted and the other
automatically propagated. Hence possible subjects of
`granted_permission` should be a subset of `require_permission`
possible subjects.

You should then use `require_permission` in your schema security
definition, since this is the one which is automatically propagated.

Example of configuration
------------------------

.. sourcecode:: python

  class granted_permission(RelationDefinition):
      subject = 'Project'
      object = 'CWPermission'

  class require_permission(RelationDefinition):
      subject = ('Project', 'Version')
      object = 'CWPermission'

  class Project(EntityType):
      """a project, only visible to managers and users having the 'view' local permission
      """
      __permissions__ = {
         'read':   ('managers', ERQLExpression('X require_permission P, P name "view", '
                                               'U has_group_permission P'),),
         'update': ('managers', 'owners',),
         'delete': ('managers', ),
         'add':    ('managers', 'users',),)
         }

  class Version(EntityType):
      """a version defines the content of a particular project's release"""
      __permissions__ = {
         'read':   ('managers', ERQLExpression('X require_permission P, P name "view", '
                                               'U has_group_permission P'),),
         'update': ('managers', 'owners',),
         'delete': ('managers', ),
         'add':    ('managers', 'users',),)
         }

  class version_of(RelationDefinition):
      """link a version to its project. A version is necessarily linked to one and
      only one project.
      """
      __permissions__ = {
         'read':   ('managers', 'users',),
         'delete': ('managers', ),
         'add':    ('managers', RRQLExpression('O require_permission P, P name "manage",'
                                               'U has_group_permission P'),)
                     }
      subject = 'Version'
      object = 'Project'
      cardinality = '1*'


This configuration indicates that we've two distinct permissions
(forthcoming `CWPermission` entities):

* one named 'view', which allows some users to view a particular
  project and its versions

* another named "manage" which provides rights to create new versions
  on a project

.. Note::

  Notice that we granted 'add' permission of `Version` to the 'users'
  group.  The idea is that it's hard for the web ui to get 'add'
  permission until the entity doesn't exist yet.  So we let the
  'version_of' relation carry the security (easier to check, since we
  usually know the project on which we may want to add a version). And
  as we know that this relation is mandatory for `Version`, we also
  ensure users can only add versions on project where they have the
  "manage" permission.

  Also, we let the 'read' permission on 'version_of' not only because
  rql expression aren't supported there, but because in this case
  we know one won't be able to see a relation between two entities he
  can't see...


Now the idea is that managers will grant permission on projects, and
those will then be propagated as configured. You will want to use sets in
`cubicweb_localperms.hooks` to configure how permissions should be
propagated when desired. In our example, put in your cube's `hooks.py`
something like:

.. sourcecode:: python

  from cubicweb_localperms import hooks
  # relations where the "main" entity is the object. We could also
  # have modified hooks.S_RELS for relations where the "main" entity
  # is the subject
  hooks.O_RELS.add('version_of')


The permission given to a project will be automatically added/removed as
version are created / deleted.


Last but not least, when defining the entity class for `Project`,
defines `__permissions__` as below:

.. sourcecode:: python

     class Project(AnyEntity):
         __permissions__ = ('view', 'manage',)

So that when going on the 'security' view for a project (in 'more
actions' sub-menu by default), you should be proposed an interface to
configurate local permissions with a combo-box prefilled with proper
permission names instead of a free text input, which greatly reduces the
risk of error.

Also, you'll find in `cubicweb_localperms` some functions to ease building
of rql expression in your schema definition. Those written in above example
could be written as below using those functions:


.. sourcecode:: python

  from cubicweb_localperms import xexpr, oexpr

  class Project(EntityType):
      __permissions__ = {'read':   ('managers', xexpr('view'),),
                         'update': ('managers', 'owners',),
                         'delete': ('managers', ),
                         'add':    ('managers', 'users',),)
                         }

  class Version(EntityType):
      __permissions__ = {'read':   ('managers', xexpr('view'),),
                         'update': ('managers', 'owners',),
                         'delete': ('managers', ),
                         'add':    ('managers', 'users',),)
                         }

  class version_of(RelationDefinition):
      __permissions__ = {'read':   ('managers', 'users',),
                         'update': ('managers', 'owners',),
                         'delete': ('managers', ),
                         'add':    ('managers', oexpr('manage'),)
                        }

            

Raw data

            {
    "_id": null,
    "home_page": "http://www.cubicweb.org/project/cubicweb-localperms",
    "name": "cubicweb-localperms",
    "maintainer": "",
    "docs_url": null,
    "requires_python": "",
    "maintainer_email": "",
    "keywords": "",
    "author": "LOGILAB S.A. (Paris, FRANCE)",
    "author_email": "contact@logilab.fr",
    "download_url": "https://files.pythonhosted.org/packages/1f/45/adbdc1b9518375781011b0a93dfb80050897e9924698996433a44e6383a3/cubicweb-localperms-1.0.0.tar.gz",
    "platform": null,
    "description": "Summary\n-------\n\nThis cube allows definition of local permissions using a generic\n`CWPermission` entity type which you should use in your schema\ndefinition.\n\nA `CWPermission` entity type:\n\n* has a name and a label\n\n* means groups linked to it through the 'require_group' relation have\n  the <name> permission on entities linked through the\n  'require_permission' object relation.\n\nTo speed-up things, a 'has_group_permission' relation is automatically\nmaintained, so 'P require_group G, U in_group G' is equivalent to 'U\nhas_group_permission P'.\n\nClient cubes should explicitly add 'X granted_permission CWPermission'\nand 'X require_permission CWPermission' for each type that should have\nlocal permission, the first one being explicitly granted and the other\nautomatically propagated. Hence possible subjects of\n`granted_permission` should be a subset of `require_permission`\npossible subjects.\n\nYou should then use `require_permission` in your schema security\ndefinition, since this is the one which is automatically propagated.\n\nExample of configuration\n------------------------\n\n.. sourcecode:: python\n\n  class granted_permission(RelationDefinition):\n      subject = 'Project'\n      object = 'CWPermission'\n\n  class require_permission(RelationDefinition):\n      subject = ('Project', 'Version')\n      object = 'CWPermission'\n\n  class Project(EntityType):\n      \"\"\"a project, only visible to managers and users having the 'view' local permission\n      \"\"\"\n      __permissions__ = {\n         'read':   ('managers', ERQLExpression('X require_permission P, P name \"view\", '\n                                               'U has_group_permission P'),),\n         'update': ('managers', 'owners',),\n         'delete': ('managers', ),\n         'add':    ('managers', 'users',),)\n         }\n\n  class Version(EntityType):\n      \"\"\"a version defines the content of a particular project's release\"\"\"\n      __permissions__ = {\n         'read':   ('managers', ERQLExpression('X require_permission P, P name \"view\", '\n                                               'U has_group_permission P'),),\n         'update': ('managers', 'owners',),\n         'delete': ('managers', ),\n         'add':    ('managers', 'users',),)\n         }\n\n  class version_of(RelationDefinition):\n      \"\"\"link a version to its project. A version is necessarily linked to one and\n      only one project.\n      \"\"\"\n      __permissions__ = {\n         'read':   ('managers', 'users',),\n         'delete': ('managers', ),\n         'add':    ('managers', RRQLExpression('O require_permission P, P name \"manage\",'\n                                               'U has_group_permission P'),)\n                     }\n      subject = 'Version'\n      object = 'Project'\n      cardinality = '1*'\n\n\nThis configuration indicates that we've two distinct permissions\n(forthcoming `CWPermission` entities):\n\n* one named 'view', which allows some users to view a particular\n  project and its versions\n\n* another named \"manage\" which provides rights to create new versions\n  on a project\n\n.. Note::\n\n  Notice that we granted 'add' permission of `Version` to the 'users'\n  group.  The idea is that it's hard for the web ui to get 'add'\n  permission until the entity doesn't exist yet.  So we let the\n  'version_of' relation carry the security (easier to check, since we\n  usually know the project on which we may want to add a version). And\n  as we know that this relation is mandatory for `Version`, we also\n  ensure users can only add versions on project where they have the\n  \"manage\" permission.\n\n  Also, we let the 'read' permission on 'version_of' not only because\n  rql expression aren't supported there, but because in this case\n  we know one won't be able to see a relation between two entities he\n  can't see...\n\n\nNow the idea is that managers will grant permission on projects, and\nthose will then be propagated as configured. You will want to use sets in\n`cubicweb_localperms.hooks` to configure how permissions should be\npropagated when desired. In our example, put in your cube's `hooks.py`\nsomething like:\n\n.. sourcecode:: python\n\n  from cubicweb_localperms import hooks\n  # relations where the \"main\" entity is the object. We could also\n  # have modified hooks.S_RELS for relations where the \"main\" entity\n  # is the subject\n  hooks.O_RELS.add('version_of')\n\n\nThe permission given to a project will be automatically added/removed as\nversion are created / deleted.\n\n\nLast but not least, when defining the entity class for `Project`,\ndefines `__permissions__` as below:\n\n.. sourcecode:: python\n\n     class Project(AnyEntity):\n         __permissions__ = ('view', 'manage',)\n\nSo that when going on the 'security' view for a project (in 'more\nactions' sub-menu by default), you should be proposed an interface to\nconfigurate local permissions with a combo-box prefilled with proper\npermission names instead of a free text input, which greatly reduces the\nrisk of error.\n\nAlso, you'll find in `cubicweb_localperms` some functions to ease building\nof rql expression in your schema definition. Those written in above example\ncould be written as below using those functions:\n\n\n.. sourcecode:: python\n\n  from cubicweb_localperms import xexpr, oexpr\n\n  class Project(EntityType):\n      __permissions__ = {'read':   ('managers', xexpr('view'),),\n                         'update': ('managers', 'owners',),\n                         'delete': ('managers', ),\n                         'add':    ('managers', 'users',),)\n                         }\n\n  class Version(EntityType):\n      __permissions__ = {'read':   ('managers', xexpr('view'),),\n                         'update': ('managers', 'owners',),\n                         'delete': ('managers', ),\n                         'add':    ('managers', 'users',),)\n                         }\n\n  class version_of(RelationDefinition):\n      __permissions__ = {'read':   ('managers', 'users',),\n                         'update': ('managers', 'owners',),\n                         'delete': ('managers', ),\n                         'add':    ('managers', oexpr('manage'),)\n                        }\n",
    "bugtrack_url": null,
    "license": "LGPL",
    "summary": "allow definition of local permissions",
    "version": "1.0.0",
    "project_urls": {
        "Homepage": "http://www.cubicweb.org/project/cubicweb-localperms"
    },
    "split_keywords": [],
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "842394751ddaae102ce22e999f11e7f31fbf194b0ef90dcd3b5d6f7881faf099",
                "md5": "1a6b7d3f9782066400089f6401fe820a",
                "sha256": "2fd988166759540965469ad9a7969acc60bf1ec73265988b284a15abe1fad968"
            },
            "downloads": -1,
            "filename": "cubicweb_localperms-1.0.0-py3-none-any.whl",
            "has_sig": false,
            "md5_digest": "1a6b7d3f9782066400089f6401fe820a",
            "packagetype": "bdist_wheel",
            "python_version": "py3",
            "requires_python": null,
            "size": 18914,
            "upload_time": "2023-08-11T07:17:48",
            "upload_time_iso_8601": "2023-08-11T07:17:48.790855Z",
            "url": "https://files.pythonhosted.org/packages/84/23/94751ddaae102ce22e999f11e7f31fbf194b0ef90dcd3b5d6f7881faf099/cubicweb_localperms-1.0.0-py3-none-any.whl",
            "yanked": false,
            "yanked_reason": null
        },
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "1f45adbdc1b9518375781011b0a93dfb80050897e9924698996433a44e6383a3",
                "md5": "3106f891338207b823a8be7998f71dac",
                "sha256": "bd603ad3e371e16d387c00640bdd20fc1a56835ce8f0fa4e276e56f01a9d20d7"
            },
            "downloads": -1,
            "filename": "cubicweb-localperms-1.0.0.tar.gz",
            "has_sig": false,
            "md5_digest": "3106f891338207b823a8be7998f71dac",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 15608,
            "upload_time": "2023-08-11T07:17:50",
            "upload_time_iso_8601": "2023-08-11T07:17:50.513334Z",
            "url": "https://files.pythonhosted.org/packages/1f/45/adbdc1b9518375781011b0a93dfb80050897e9924698996433a44e6383a3/cubicweb-localperms-1.0.0.tar.gz",
            "yanked": false,
            "yanked_reason": null
        }
    ],
    "upload_time": "2023-08-11 07:17:50",
    "github": false,
    "gitlab": false,
    "bitbucket": false,
    "codeberg": false,
    "lcname": "cubicweb-localperms"
}
        
Elapsed time: 0.24513s