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

Важливо

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

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

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

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

Однак:

• Ми не хочемо, щоб треті сторони мали прямий доступ до властивостей.

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

• Агентам з нерухомості не потрібно вирішувати, які типи власності або теги доступні.

• Агенти з нерухомості можуть мати ексклюзивну нерухомість, ми не хочемо, щоб один агент міг керувати ексклюзивністю іншого.

• Усі агенти з нерухомості повинні мати можливість підтвердити продаж майна, яким вони можуть керувати, але ми не хочемо, щоб вони могли підтверджувати або позначати як оплачені будь-які рахунки-фактури в системі.

Примітка

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

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

Групи

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

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

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

Ціль

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

• Ми можемо зробити співробітників агентами з нерухомості або менеджерами з нерухомості.

• Користувач admin є менеджером нерухомості.

• У нас новий співробітник агент з нерухомості без доступу до виставлення рахунків або адміністрування.

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

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

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

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

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

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

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

Exercise

1. Створіть файл security.xml у відповідній папці та додайте його до файлу __manifest__.py.

2. Якщо ще цього немає, додайте поле 'category' до свого __manifest__.py зі значенням Real Estate/Brokerage.

3. Додайте запис, створюючи групу з ідентифікатором estate_group_user, назвою «Агент» і категорією base.module_category_real_estate_brokerage.

4. Нижче додайте запис, створюючи групу з ідентифікатором 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

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

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

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

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

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

Ціль

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

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

• Агенти з нерухомості не зможуть оновлювати типи власності або теги.

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

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

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

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

група	створити	читати	оновити	вилучити
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).

• Виклик методу 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.

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

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

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

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

Exercise

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

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

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

1

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

2

Для додатків, які будуть використовуватися більшістю або всіма співробітниками, роль «користувач додатку» може бути скасована, а її можливості надані всім співробітникам безпосередньо, наприклад, загалом усі співробітники можуть подати витрати або взяти відпустку.