flectra/doc/reference/security.rst

101 lines
3.4 KiB
ReStructuredText
Raw Permalink Normal View History

2018-03-30 13:42:41 +02:00
:banner: banners/flectra_security.jpg
.. _reference/security:
2018-03-14 10:18:18 +01:00
===================
2018-02-12 08:55:56 +01:00
Security in Flectra
2018-03-14 10:18:18 +01:00
===================
2018-02-12 08:55:56 +01:00
Aside from manually managing access using custom code, Flectra provides two main
data-driven mechanisms to manage or restrict access to data.
Both mechanisms are linked to specific users through *groups*: a user belongs
to any number of groups, and security mechanisms are associated to groups,
thus applying security mechamisms to users.
.. _reference/security/acl:
Access Control
==============
Managed by the ``ir.model.access`` records, defines access to a whole model.
Each access control has a model to which it grants permissions, the
permissions it grants and optionally a group.
Access controls are additive, for a given model a user has access all
permissions granted to any of its groups: if the user belongs to one group
which allows writing and another which allows deleting, they can both write
and delete.
If no group is specified, the access control applies to all users, otherwise
it only applies to the members of the given group.
Available permissions are creation (``perm_create``), searching and reading
(``perm_read``), updating existing records (``perm_write``) and deleting
existing records (``perm_unlink``)
.. _reference/security/rules:
Record Rules
============
Record rules are conditions that records must satisfy for an operation
(create, read, update or delete) to be allowed. It is applied record-by-record
after access control has been applied.
A record rule has:
* a model on which it applies
* a set of permissions to which it applies (e.g. if ``perm_read`` is set, the
rule will only be checked when reading a record)
* a set of user groups to which the rule applies, if no group is specified
the rule is *global*
* a :ref:`domain <reference/orm/domains>` used to check whether a given record
matches the rule (and is accessible) or does not (and is not accessible).
The domain is evaluated with two variables in context: ``user`` is the
current user's record and ``time`` is the `time module`_
Global rules and group rules (rules restricted to specific groups versus
groups applying to all users) are used quite differently:
* Global rules are subtractive, they *must all* be matched for a record to be
accessible
* Group rules are additive, if *any* of them matches (and all global rules
match) then the record is accessible
This means the first *group rule* restricts access, but any further
*group rule* expands it, while *global rules* can only ever restrict access
(or have no effect).
.. warning:: record rules do not apply to the Administrator user
:class: aphorism
although access rules do
.. _reference/security/fields:
Field Access
============
2018-02-12 08:55:56 +01:00
An ORM :class:`~flectra.fields.Field` can have a ``groups`` attribute
providing a list of groups (as a comma-separated string of
:term:`external identifiers`).
If the current user is not in one of the listed groups, he will not have
access to the field:
* restricted fields are automatically removed from requested views
2018-02-12 08:55:56 +01:00
* restricted fields are removed from :meth:`~flectra.models.Model.fields_get`
responses
* attempts to (explicitly) read from or write to restricted fields results in
an access error
.. todo::
field access groups apply to administrator in fields_get but not in
read/write...
.. _foo: http://google.com
2018-03-14 10:18:18 +01:00
.. _time module: https://docs.python.org/3/library/time.html