Модель безопасности

Оглавление

Права доступа

Права доступа - определяет какие права доступа имееют члены указанных групп пользователей к записям указанной модели. Контроль доступа осуществляется с помощью модели ir.model.access. Как правило все записи данной модели пишутся в csv файл с именем модели ir.model.access.csv и указывается в файле __manifest__.py. В нашем случае это выглядит вот так:

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_first_model_base_group_user,first_model base_group_user,first_module.model_first_model,base.group_user,1,1,1,1

При этом, эту запись вы можете указать и в виде xml файла:


<record id="access_first_model_base_group_user" model="ir.model.access">
    <field name="name">first_model base_group_user</field>
    <field name="model_id" ref="first_module.model_first_model"/>
    <field name="group_id" ref="base.group_user"/>
    <field name="perm_read" eval="True"/>
    <field name="perm_write" eval="True"/>
    <field name="perm_create" eval="True"/>
    <field name="perm_unlink" eval="True"/>
</record>

Правила записей

Подготовка

Для того, чтобы использовать следующий пример, вам необходимо переключить текущий разрабатываемый проект на другую ветку.

Вот ее имя - 16.0-security-example

Затем удалите текущую базу и создайте новую.

Убедитесь, что у вас не осталось вкладок со старыми сессиями

Обзор системы

При первом входе в систему вы не сможете увидеть привычный вам ранее пункт меню First Model Root. Для того, чтобы мы смогли им воспользоваться это сделать нам нужно зайти в настройки нашего текущего пользователя:

Откройте настройки текущего сотрудника

Установите для вашего пользователя для приложения First Module уровень доступа Employee:

Выберите уровень доступа - Сотрудник

После этого обновите страницу. И в главном меню у вас уже появится знакомы нам пункт меню:

Доступные записи сотруднику

Теперь давайте рассмотрим что и как у нас сделано с точки зрения кода:

Организация групп

  1. Здесь мы объявили категорию для групп пользователей, которые будут регулировать доступ внутри нашего приложения.
  2. Объявили сами группы. У нас их три и они нужны нам, для того, чтобы в дальнейшем рассмотреть детально сценарии с правилами записей
  3. Как вы можете видеть все группы ссылаются на одну и ту же категорию

Более того, в правом верхнем углу, вы можете видеть окно что при выборе группы доступа наш пользователь входит только в одну группу Employee. А теперь давайте выберем для него группу Manager:

Выбор группы Manager

И давайте посмотрим на выбор группы Administrator:

Выбор группы Administrator

Как вы можете видеть, каждый раз, когда мы мы выбираем права доступа с повышенными привилегиями наш пользователь входи не только в старшую группу, но и в младшие. На уровне кода это организовано следующим образом:

Иерархия групп

Такая реализация иерархии нужна для того, чтобы можно было использовать весьма тонкие настройки безопасности - Правила записей.

Теперь когда уже понимаем как устроена иерархия групп, давайте еще посмотрим на права доступа:

Текущие права доступа

Как вы можете видеть у на все группы могут читать и писать записи, Менеджеры могут еще и создавать, а Администраторы и удалять.

Но если мы добавим нашего пользователя в группу Employees, то мы увидим не 3 а две записи.

И вот мы подошли к тому, что есть механизм более тонкой настройки доступа на уровне записей.

Правила записей

В нашем мы использует следующее правило записи:

Правило записи для Employee

  1. Домен - к записям, которые попадают под его условия, будут применяться ниже указанные доступы. В текущем примере мы хотим отфильтровать все записи у которых значение поля field_one не равно 30, 25 или 40. И наша запись с именем record 003 как раз имеет значение поля field_one равным 30 и мы поэтому ее перестали видеть, а вот почему - читайте ниже.
  2. Список групп, к которым будет применяться данное правило
  3. Доступ на чтение - если True, то при попытке чтения записей из указанной модели будут проверены группы пользователя, к которым принадлежит пользователь, и если он находится в группе указанной в пункте 2, то для него доступными для чтения останутся только те записи, которые соответствуют условиям домена из пункта 1. Т.е. по условиям прав доступа вы можете читать все записи из указанной модели, но при использовании данного правила доступ на чтение останется только для записей из домен в п. 1. Если же параметр равен False, то данное правило не будет применяться к запросам на чтение и вы сможете увидеть все записи. Попробуйте это сделать самостоятельно - измените параметр и перезапустите систему с обновлением
  4. Доступ на изменения (запись) - принцип аналогичен для чтения из п.3
  5. Доступ на создание - принцип аналогичен для чтения из п.3
  6. Доступ на удаление - принцип аналогичен для чтения из п.3

Теперь давайте добавим нашего пользователя пользователя в группу Manager. Обновим страницу и после этого, мы можем увидеть, что нам доступны все три записи. Давайте зайдем в запись c именем record 003 и попытаемся изменить ее имя а после этого сохранить:

Изменяем запись record 003

И вот какой результат мы получим:

Ограничение правил доступа

  1. При попытке сохранить система предотвратила ее. И сообщает нам что для нашего пользователя с именем Mitchel Admin при попытке изменить запись с именем record 003 этого сделать не удалось, т.к. данное действие не позволено правилом с именем Records: field one is not еqual 30, 25, 40
  2. Обратите внимание не домен, это так называемые безусловный домен - он применяется чтобы ничего не фильтровать
  3. Данное правило будет применяться для группы Manager
  4. Доступ на чтение в этом случае True и это означает что для пользователей из п.3 будет применяться безусловный домен из п.2 Т.е. все пользователи входящие в группу Manager смогут видеть все записи из модели first.model
  5. Доступ на изменение в этом правиле не применяется и поэтому для при попытке изменения будут проверяться правила которые доступны для других групп. И поскольку будучи менеджером мы автоматически являемся участником группы Employee а для них действует правило которое ограничивает чтение и изменение всех записей, у которых значение поля field_one равным 30, 25 или 40, то в этом случае нам система и не позволяет изменить эту запись.
  6. Доступ на создание. В данном случае он равен True, но поскольку мы и так по правам доступа можем это делать и домен записи безусловный, данное значение ни на что не влияет

Задания для самостоятельного повторения:

  1. Самостоятельно добавьте пользователя в группу Administrator
  2. Попробуйте изменить запись с именем record 003
  3. Сформулируйте объяснение почему у вас получился такой результат