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

Важливо

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

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

Будь-який співробітник (що означає group_user) може створювати, читати, оновлювати або видаляти властивості, типи властивостей або теги властивостей.
Якщо встановлено estate_account, лише агенти, яким дозволено взаємодіяти з виставленням рахунків, можуть підтверджувати продажі, оскільки це необхідно для створення рахунка-фактури.

Однак:

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

Примітка

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

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

Групи¶

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

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

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

Ціль

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

Ми можемо зробити співробітників агентами з нерухомості або менеджерами з нерухомості.
Користувач 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

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

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

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

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

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

Ціль

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

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

Права доступу вперше були представлені в Розділ 5: Безпека - короткий вступ.

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

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

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

група	створити	читати	Оновлення	вилучити
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="[(4, 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).
Виклик методу check_access_rights(operation) на рекорсеті перевіряє, чи має поточний користувач доступ до самої моделі.
Виклик check_access_rule(operations) на непорожньому наборі перевіряє, що поточному користувачеві дозволено виконувати операцію над кожним записом набору.

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

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

Exercise

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

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

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

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

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

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

Ціль

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

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

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

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

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

Правила для кількох компаній - це просто правила запису на основі полів 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>

Небезпека

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

Exercise

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

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

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

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

Ціль

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

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

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

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

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

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

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

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

Exercise

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

Меню налаштувань лише додає шуму до їхнього інтерфейсу, воно має бути видимим лише для менеджерів.

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

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

Edit on GitHub