Обмеження доступу до даних¶

Важливо

This tutorial is an extension of the Server framework 101 tutorial. Make sure you have completed it and use the estate module you have built as a base for the exercises in this tutorial.

Поки що ми здебільшого займалися впровадженням корисних функцій. Однак у більшості бізнес-сценаріїв безпека швидко стає проблемою: зараз

Будь-який співробітник (що означає group_user) може створювати, читати, оновлювати або видаляти властивості, типи властивостей або теги властивостей.
If estate_account is installed then only agents allowed to interact with invoicing can confirm sales as that’s necessary to create an invoice.

Однак:

Ми не хочемо, щоб треті сторони мали прямий доступ до властивостей.
Не всі наші співробітники можуть бути агентами з нерухомості (наприклад, адміністративний персонал, менеджери нерухомості, …), ми не хочемо, щоб люди, які не є агентами, бачили наявні властивості.
Агентам з нерухомості не потрібно вирішувати, які типи власності або теги доступні.
Real-estate agents can have exclusive properties, we do not want one agent to be able to manage another’s exclusives.
Усі агенти з нерухомості повинні мати можливість підтвердити продаж майна, яким вони можуть керувати, але ми не хочемо, щоб вони могли підтверджувати або позначати як оплачені будь-які рахунки-фактури в системі.

Примітка

Насправді деякі або більшість із них можуть підійти для малого бізнесу.

Because it’s easier for users to disable unnecessary security rules than it is to create them from nothing, it’s better to err on the side of caution and limit access: users can relax that access if necessary or convenient.

Групи¶

Перегляньте також

Документацію, пов’язану з цією темою, можна знайти в довіднику щодо безпеки.

Інструкції з кодування документують формат і розташування елементів основних даних.

Ціль

У кінці цього розділу

Ми можемо зробити співробітників агентами з нерухомості або менеджерами з нерухомості.
Користувач admin є менеджером нерухомості.
У нас новий співробітник агент з нерухомості без доступу до виставлення рахунків або адміністрування.

Було б непрактично прикріплювати індивідуальні правила безпеки до співробітників щоразу, коли нам потрібні зміни, щоб групи пов’язували правила безпеки та користувачів. Вони відповідають ролям, які можуть бути призначені співробітниками.

Для більшості додатків Odoo 1 хорошим базовим сценарієм є наявність ролей користувача та менеджера (або адміністратора): менеджер може змінювати конфігурацію додатків та контролювати її використання в цілому, а користувач може, використовувати додаток 2.

Ця базова лінія здається нам достатньою:

Менеджери з нерухомості можуть налаштовувати систему (керувати доступними типами та тегами), а також контролювати кожну нерухомість у процесі розробки.
Агенти з нерухомості можуть управляти майном, яким вони опікуються, або майном, яке не перебуває під опікою жодного агента.

Згідно з природою Odoo, що керується даними, група - це не більше ніж запис моделі res.groups. Зазвичай вони є частиною основних даних модуля, визначених в одному з файлів даних модуля.

Як простий приклад можна знайти тут.

Exercise

Створіть файл security.xml у відповідній папці та додайте його до файлу __manifest__.py.
Якщо ще цього немає, додайте поле 'category' до свого __manifest__.py зі значенням Real Estate/Brokerage.
Додайте запис, створюючи групу з ідентифікатором estate_group_user, назвою «Агент» і категорією base.module_category_real_estate_brokerage.
Нижче додайте запис, створюючи групу з ідентифікатором estate_group_manager, назвою «Менеджер» і категорією base.module_category_real_estate_brokerage. Група estate_group_manager має означати estate_group_user.

Примітка

Звідки ця категорія? Це модульна категорія. Тут ми використали ідентифікатор категорії base.module_category_real_estate_brokerage, який було автоматично згенеровано Odoo на основі category, встановленого в __manifest__.py модуля. Ви також можете знайти тут список категорій модулів за замовчуванням, наданий Odoo.

Порада

Оскільки ми змінили файли даних, не забудьте перезапустити Odoo та оновити модуль за допомогою -u estate.

Якщо ви перейдете до Налаштування ‣ Управління кортстувачами і відкриєте користувача admin («Mitchell Admin»), ви побачите новий розділ:

Налаштуйте адміністратора як Менеджер нерухомості.

Exercise

Через веб-інтерфейс створіть нового користувача лише з доступом «агент з нерухомості». Користувач не повинен мати доступ до виставлення рахунків або адміністрування.

Використовуйте приватну вкладку або вікно, щоб увійти з новим користувачем (не забудьте встановити пароль), як агент з нерухомості ви повинні бачити лише додаток нерухомості та, можливо, додаток для Обговорення (чат):

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

Перегляньте також

Документацію щодо цієї теми можна знайти за адресою Права доступу.

Ціль

У кінці цього розділу

Співробітники, які не є принаймні агентами з нерухомості, не бачитимуть додаток нерухомості.
Агенти з нерухомості не зможуть оновлювати типи власності або теги.

Access rights were first introduced in Chapter 4: Security - A Brief Introduction.

Права доступу - це спосіб надати користувачам доступ до моделей через групи: прив’яжіть право доступу до групи, тоді всі користувачі цієї групи матимуть доступ.

Наприклад, ми не хочемо, щоб агенти з нерухомості могли змінювати доступні типи власності, тому ми не будемо пов’язувати цей доступ із групою «користувач».

Права доступу можуть лише надати доступ, але не можуть його видалити: коли доступ перевіряється, система перевіряє, чи будь-які права доступу, пов’язані з користувачем (через будь-яку групу), надають цей доступ.

група	створити	читати	Оновлення	вилучити
A	X	X
B		X
C			X

Користувач із групами A та C зможе робити що завгодно, крім видалення об’єкта, тоді як користувач із групами B та C зможе читати та оновлювати його, але не створювати чи видаляти.

Примітка

Групу прав доступу можна опустити, це означає, що ACL застосовується до кожного користувача, це корисний, але ризикований запасний варіант, оскільки залежно від встановлених додатків він може надати доступ до моделі навіть некористувачам.
Якщо права доступу не застосовуються до користувача, йому не надається доступ (відмовлено за замовчуванням).
Якщо пункт меню вказує на модель, до якої користувач не має доступу та не має підменю, які користувач може бачити, меню не відображатиметься.

Exercise

Оновіть файл прав доступу до:

Надайте повний доступ до всіх об’єктів вашій групі Менеджер нерухомості.
Надайте агентам (користувачам нерухомості) доступ лише для читання типів і тегів.
Не давайте нікому права видаляти властивості.
Переконайтеся, що ваш користувач-агент не може змінювати типи чи теги чи видаляти властивості, але він може іншим чином створювати або оновлювати властивості.

Попередження

Не забувайте надавати різні xid вашим записам ir.model.access, інакше вони перезаписуватимуть один одного.

Оскільки «демонстраційного» користувача не було призначено агентом або менеджером з нерухомості, він навіть не повинен мати можливість бачити програму з нерухомості. Використовуйте приватну вкладку або вікно, щоб перевірити це (користувач «demo» має пароль «demo»).

Правила запису¶

Перегляньте також

Документацію щодо цієї теми можна знайти за адресою Правила запису.

Ціль

У кінці цього розділу агенти не зможуть бачити властивості, ексклюзивні для їхніх колег; але менеджери все одно зможуть все бачити.

Права доступу можуть надати доступ до всієї моделі, але часто нам потрібно бути більш конкретними: хоча агент може взаємодіяти з властивостями загалом, ми можемо не хотіти, щоб вони оновлювали або навіть бачили властивості, якими керує один із їхніх колег.

Правила записів забезпечують таку точність: вони можуть надавати або відхиляти доступ до окремих записів:

<record id="rule_id" model="ir.rule">
    <field name="name">A description of the rule's role</field>
    <field name="model_id" ref="model_to_manage"/>
    <field name="perm_read" eval="False"/>
    <field name="groups" eval="[Command.link(ref('base.group_user'))]"/>
    <field name="domain_force">[
        '|', ('user_id', '=', user.id),
             ('user_id', '=', False)
    ]</field>
</record>

Пошук доменів - це те, як керується доступом: якщо запис пройдено, тоді доступ надається, інакше доступ відхиляється.

Порада

Оскільки правила, як правило, досить складні й не створюються масово, їх зазвичай створюють у форматі XML, а не у форматі CSV, який використовується для прав доступу.

Правило вище:

Застосовується лише до операцій «створити», «оновити» (записати) і «видалити» (від’єднати): тут ми хочемо, щоб кожен співробітник міг бачити записи інших користувачів, але лише автор/уповноважений може оновлювати запис.
Є неглобальним, тож ми можемо надати додаткове правило для, наприклад, менеджери.
Дозволяє операцію, якщо поточний користувач (user.id) встановлено (наприклад, створено або призначено) для запису або якщо із записом взагалі немає пов’язаного користувача.

Примітка

Якщо жодне правило не визначено або не застосовується до моделі та операції, тоді операція дозволена (default-allow), це може мати дивні наслідки, якщо права доступу встановлено неправильно (є надто дозволеним).

Exercise

Визначте правило, яке обмежує агентам лише можливість переглядати або змінювати властивості, у яких немає продавця або для яких вони є продавцем.

Ви можете створити другого користувача агента з нерухомості або створити кілька властивостей, для яких продавець є менеджером або іншим користувачем.

Переконайтеся, що ваші менеджери з нерухомості все ще можуть бачити всі властивості. Якщо ні, то чому? Пам’ятайте:

Група estate_group_manager має означати estate_group_user.

Перевизначення безпеки¶

Обхід безпеки¶

Ціль

Наприкінці цього розділу агенти мають мати можливість підтверджувати продаж нерухомості без доступу до виставлення рахунків.

Якщо ви спробуєте позначити нерухомість як «продану» як агент з нерухомості, ви повинні отримати помилку доступу:

Це відбувається тому, що estate_account намагається створити рахунок-фактуру під час процесу, але для створення рахунку-фактури потрібне право на керування всіма рахунками-фактурами.

Ми хочемо, щоб агенти могли підтверджувати продаж, не маючи повного доступу до виставлення рахунків, а це означає, що нам потрібно обійти звичайні перевірки безпеки Odoo, щоб створити рахунок-фактуру, незважаючи на те, що поточний користувач не має на це права.

Є два основні способи обійти існуючі перевірки безпеки в Odoo, навмисно або як побічний ефект:

Метод sudo() створить новий набір записів у «режимі sudo», це ігнорує всі права доступу та правила запису (хоча жорстко закодовані перевірки груп і користувачів можуть застосовуватися).
Виконання необроблених запитів SQL обійде права доступу та правила запису як побічний ефект обходу самого ORM.

Exercise

Оновіть estate_account, щоб обійти права доступу та правила під час створення рахунка-фактури.

Небезпека

Загалом слід уникати цих функцій і використовувати їх лише з особливою обережністю після перевірки того, що поточний користувач і операція мають змогу обійти звичайну перевірку прав доступу.

Операції, що виконуються в таких режимах, також повинні якомога менше покладатися на введення користувача та перевіряти його якомога більше.

Програмна перевірка безпеки¶

Ціль

Наприкінці цього розділу створення рахунка-фактури має бути стійким до проблем безпеки незалежно від змін у estate.

В Odoo права доступу та правила запису перевіряються лише під час доступу до даних через ORM, наприклад. створення, читання, пошук, запис або роз’єднання запису за допомогою методів ORM. Інші методи не обов’язково перевіряють будь-які права доступу.

У попередньому розділі ми обійшли правила запису під час створення рахунка-фактури в action_sold. До цього обходу може отримати доступ будь-який користувач без перевірки прав доступу:

Додайте друк до action_sold в estate_account перед створенням рахунка-фактури (оскільки створення рахунка-фактури отримує доступ до власності, тому запускає перевірку ACL), наприклад:
```
print(" reached ".center(100, '='))
```

У журналі Odoo має з’явитися досягнуто, а потім повідомлення про помилку доступу.

Небезпека

Те, що ви вже використовуєте код Python, не означає, що будь-які права доступу чи правила перевіряються чи будуть перевірені.

На даний момент доступ неявно перевіряється шляхом доступу до даних на self, а також виклику super() (який робить те саме та оновлює self), викликаючи помилки доступу та скасовуючи транзакцію, «скасовуючи» наш рахунок.

Однак, якщо це зміниться в майбутньому, або ми додамо побічні ефекти до методу (наприклад, звіт про продаж державній установі), або в estate буде введено помилки, … не агенти зможуть ініціювати операції, до яких вони не повинні мати доступу.

Тому під час виконання операцій, не пов’язаних із CRUD, або законного обходу ORM чи безпеки, або під час запуску інших побічних ефектів надзвичайно важливо виконувати явні перевірки безпеки.

Явні перевірки безпеки можуть виконуватися:

Перевірка поточного користувача (self.env.user) і зіставлення його з конкретними моделями або записами.
Перевірка того, що поточний користувач має певні групи, жорстко закодовані для дозволу або заборони операції (self.env.user.has_group).
Calling the check_access_rights(operation) method on a recordset, this verifies whether the current user has access to the model itself.
Calling check_access_rule(operations) on a non-empty recordset, this verifies that the current user is allowed to perform the operation on every record of the set.

Попередження

Перевірка прав доступу та перевірка правил запису є окремими операціями, якщо ви перевіряєте правила запису, зазвичай потрібно попередньо перевірити права доступу.

Exercise

Before creating the invoice, use check_access_rights and check_access_rule to ensure that the current user can update properties in general as well as the specific property the invoice is for.

Повторно запустіть сценарій обходу, переконайтеся, що помилка виникає перед друком.

Безпека мульти-компаній¶

Перегляньте також

Інструкції для мульти-компаній for an overview of multi-company facilities in general, and multi-company security rules in particular.

Документацію про правила в цілому можна знайти за адресою Правила запису.

Ціль

Наприкінці цього розділу агенти повинні мати доступ лише до властивостей свого агентства (або агентств).

For one reason or another we might need to manage our real-estate business as multiple companies e.g. we might have largely autonomous agencies, a franchise setup, or multiple brands (possibly from having acquired other real-estate businesses) which remain legally or financially separate from one another.

Odoo can be used to manage multiple companies inside the same system, however the actual handling is up to individual modules: Odoo itself provides the tools to manage the issue of company-dependent fields and multi-company rules, which is what we’re going to concern ourselves with.

Ми хочемо, щоб різні агенції були «відокремлені» одна від одної, щоб властивості належали певній агенції, а користувачі (незалежно від того, агенти чи менеджери) могли бачити лише властивості, пов’язані з їх агенцією.

Як і раніше, оскільки це базується на нетривіальних записах, користувачеві легше послабити правила, ніж посилити їх, тому має сенс за замовчуванням використовувати відносно сильнішу модель безпеки.

Правила для кількох компаній - це просто правила запису на основі полів company_ids або company_id:

company_ids - це всі компанії, до яких має доступ поточний користувач
company_id - це поточна активна компанія (та, у якій зараз працює користувач).

Правила для кількох компаній зазвичай використовують перше, тобто перевіряють, чи пов’язаний запис з однією з компаній, до яких користувач має доступ:

<record model="ir.rule" id="hr_appraisal_plan_comp_rule">
    <field name="name">Appraisal Plan multi-company</field>
    <field name="model_id" ref="model_hr_appraisal_plan"/>
    <field name="domain_force">[
        '|', ('company_id', '=', False),
             ('company_id', 'in', company_ids)
    ]</field>
</record>

Небезпека

Multi-company rules are usually global, otherwise there is a high risk that additional rules would allow bypassing the multi-company rules.

Exercise

Додайте поле company_id до estate.property, воно повинно бути обов’язковим (ми не хочемо власності без агентства), і за умовчанням має бути поточна компанія поточного користувача.
Створіть нову компанію з новим агентом з нерухомості в цій компанії.
Менеджер повинен бути учасником обох компаній.
Старий агент має бути лише членом старої компанії.
Створіть кілька властивостей у кожній компанії (використовуйте селектор компанії як менеджера або використовуйте агентів). Скасуйте налаштування продавця за умовчанням, щоб уникнути запуску цього правила.
Усі агенти можуть бачити всі компанії, що небажано, додайте правило запису, яке обмежує таку поведінку.

Попередження

не забудьте --update свій модуль, коли змінюєте його модель або дані

Видимість != безпека¶

Ціль

At the end of this section, real-estate agents should not see the Settings menu of the real-estate application, but should still be able to set the property type or tags.

Конкретні моделі Odoo можна пов’язувати безпосередньо з групами (або компаніями, або користувачами). Перед використанням важливо з’ясувати, чи є цей зв’язок функцією безпеки чи видимості:

Visibility features mean a user can still access the model or record otherwise, either through another part of the interface or by performing operations remotely using RPC, things might just not be visible in the web interface in some contexts.
Функції Безпеки означають, що користувач не може отримати доступ до записів, полів або операцій.

Ось кілька прикладів:

Групи в полях моделі (в Python) є функцією безпеки, користувачі поза групою не зможуть отримати поле або навіть знати про його існування.

Приклад: у діях сервера лише користувачі системи можуть бачити або оновлювати код Python <https://github.com/odoo/odoo/blob/7058e338a980268df1c502b8b2860bdd8be9f727/odoo/addons/base/models/ir_actions.py#L414-L417> _.
Групи на перегляд елементів (у XML) є функцією видимості, користувачі поза групою не зможуть побачити елемент або його вміст у формі, але вони зможуть взаємодіяти з об’єктом (включно з цим полем).

Приклад: лише менеджери мають миттєвий фільтр для перегляду листів своїх команд.
Групи в меню та діях є функціями видимості, меню чи дія не відображатимуться в інтерфейсі, але це не перешкоджає прямій взаємодії з основним об’єктом.

Приклад: лише системні адміністратори можуть бачити меню налаштувань ел. навчання.

Exercise

Real Estate agents can not add property types or tags, but can see their options from the Property form view when creating it.

The Settings menu just adds noise to their interface, make it only visible to managers.

Незважаючи на відсутність доступу до меню Типи властивостей і Теги властивостей, агенти все ще можуть отримувати доступ до базових об’єктів, оскільки вони все ще можуть вибирати теги або тип для встановлення своїх властивостей.

1: Додаток Odoo - це група пов’язаних модулів, що охоплюють бізнес-сферу чи галузь, зазвичай складається з базового модуля та низки розширень на цій основі для додавання додаткових чи спеціальних функцій або зв’язку з іншими бізнес-сферами.
2: Для додатків, які будуть використовуватися більшістю або всіма співробітниками, роль «користувач додатку» може бути скасована, а її можливості надані всім співробітникам безпосередньо, наприклад, загалом усі співробітники можуть подати витрати або взяти відпустку.

Edit on GitHub