→ Обмеження доступу до даних. Обмеження доступу до даних Обмеження доступу до даних 1з8

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

Восьма версія платформи «1С:Підприємство» (сьогодні 8.3) несла у собі безліч змін стосовно «сімки», серед яких особливо виділявся механізм обмеження прав доступу на рівні записів. Незважаючи на те, що можна, теоретично, обійтися і без нього, використовуючи виключно ролі, RLS дозволяє досягти більш тонкого налаштування доступу. Але для правильної експлуатації цього механізму потрібно чітко розуміти його суть і мати достатній досвід у розробці в 1С.

Що таке RLS?

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

Щоб отримати можливість писати запити для обмежень RLS, необхідно створити роль або взяти вже наявну. Налаштування RLS в 1С 8.3 може застосовуватись для наступних дій користувача:

  • Додавання;
  • Читання;
  • Вилучення;
  • Зміна.

Крім широких можливостей налаштування доступу, RLS несуть у собі й недоліки:

  1. Вимоги до кваліфікації розробника, тому що писати запит доведеться вбудованою мовою з урахуванням правил синтаксису;
  2. Відсутність можливості швидкого налагодження умови;
  3. Обмежені можливості щодо опису логіки: занадто складні умови доведеться все-таки писати в модулях документів та довідників;
  4. У клієнт-серверному варіанті баз можливе неявне зростання таблиць, включених у запит. До того ж відстежити цей процес дуже складно;
  5. Вимоги до ресурсів. Обмеження RLS споживають чимало потужності клієнтської машини і сервера;
  6. Нечисленна документація у вільному доступі.

Ще однією проблемою, яка може виникнути після налаштування 1С RLS, можуть стати звіти. Справа в тому, що розробники передбачають можливі обмеження RLS та будують звіти таким чином, щоб вони показували лише дозволені дані. Якщо у користувачів налаштовані різні обмеження RLS, то дані у звіті за однаковими параметрами у них можуть бути різні. Це може викликати питання, тому при проектуванні звітів або написанні запитів у RLS потрібно врахувати подібні ситуації.

Створюємо обмеження RLS

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

Вікно, що відкрилося, містить 2 вкладки: «Права» і «Шаблони обмежень». Щоб накласти певні обмеження на конкретну дію, необхідно виділити її та у правій нижній частині натиснути на зелений плюс. З'явиться рядок, в якому ми зможемо задати обмеження 1С RLS вбудованою в 1С мовою.


Якщо ви знаєте синтаксис 1С (як свої п'ять пальців), можете писати прямо в полі «Обмеження доступу». Розробники 1С передбачили можливість відкривати конструктор запиту, який допоможе та підкаже, на що можна зробити обмеження. Щоб його відкрити, потрібно натиснути кнопку з трьома точками (Вибрати) або F4 і з'явитися вікно з кнопкою «Конструктор запиту…».


У вікні, що з'явиться, ви зможете налаштувати обмеження не тільки по даному довіднику, але і по інших об'єктах системи. Для цього необхідно додати їх на вкладці Таблиці та поля. Прописуємо обмеження на поля довідника "Номенклатура" та натискаємо на "ОК". Уважно ставтеся до назви змінних: параметри RLS задаються під час старту сесії користувача і повинні утримуватися в об'єкті метаданих.


На вкладці «Шаблони обмежень» задаються запити, які необхідні для копіювання однакових налаштувань RLS в 1С 8.3. Після того, як ви додали свій шаблон, на його ім'я можете звертатися в налаштуваннях прав доступу.

Також можна одночасно додавати обмеження на кілька ролей. Для цього в дереві конфігурації необхідно натиснути правою кнопкою миші розділ «Ролі» і вибрати пункт «Всі ролі».


Як висновок хотілося б відзначити, що ця стаття спрямована на консультантів-розробників 1С і може допомогти в першу чергу тим, хто вже мав досвід розробки на «1С:Підприємство». Незважаючи на простоту, знання семантики та розуміння структури бізнес-процесів власного підприємства або організації замовника для правильної роздачі прав – вимагають певного рівня знань та досвіду.

1С має вбудовану систему прав доступу (ця система називається – ролі 1С). Ця система є статичною – як адміністратор поставив права 1С, і буде.

Додатково діє динамічна система прав доступу (називається – RLS 1С). У ній права 1С динамічно обчислюються на момент роботи користувача виходячи з заданих параметрів.

Однією з найпоширеніших налаштувань безпеки в різних програмах є набір дозволів на читання/запис для груп користувачів і далі – включення чи виключення користувача з груп. Наприклад, подібна система використовується у Windows AD (Active Directory).

Така система безпеки у 1С називається – Ролі 1С. Ролі 1С - це , який знаходиться в конфігурації в гілці Загальні / Ролі. Ролі 1С виступають як групи, для яких призначаються права 1С. Далі користувач включається або виключається із цієї групи.

Натиснувши двічі назву ролі 1С — Вам відкриється редактор прав для ролі 1С. Зліва – список об'єктів 1С. Виділіть будь-який і праворуч відобразяться варіанти прав доступу (як мінімум: читання, додавання, зміна, видалення).

Для верхньої гілки (назва поточної конфігурації) встановлюються адміністративні права 1С та доступ на запуск різних варіантів.

Усі права 1С поділені на дві групи – «просто» право і таке право з додаванням «інтерактивне». Що це означає?

Коли користувач відкриває будь-яку форму (наприклад, обробку) і натискає на ній кнопку – то програма вбудованою мовою 1С виконує певні дії, наприклад, видалення документів. За дозвіл цих дій (виконуваних програмно) відповідають «просто» права 1С.

Коли користувач відкриває журнал і починає щось робити з клавіатури самостійно (наприклад, вводити нові документи) – це «інтерактивні» права 1С.

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

Розріз можливостей встановлення прав доступу з допомогою ролей – об'єкт 1С. Тобто Ви можете або увімкнути доступ до довідника або вимкнути. Включити трохи не можна.

І тому існує розширення системи ролей 1С під назвою 1С RLS. Це динамічна система прав доступу, яка дозволяє частково обмежити доступ. Наприклад, користувач бачить лише документи щодо певного складу та організації та не бачить інші.

Обережно! При використанні заплутаної схеми RLS 1С у різних користувачів можуть бути питання, коли вони спробують звірити той самий звіт, сформований з-під різних користувачів.

Ви берете певний довідник (наприклад, організації) та певне право (наприклад, читання). Ви дозволяєте читання для участі 1С. На панелі Обмеження доступу до даних Ви встановлюєте текст запиту, який повертає ІСТИНА або БРЕХНЯ залежно від налаштувань. Настройки зазвичай зберігаються в регістрі відомостей (наприклад, регістр відомостей конфігурації Бухгалтерія НалаштуванняПравДоступуКористувачів).

Цей запит виконується динамічно (при спробі реалізувати читання) для кожного запису довідника. Таким чином, для тих записів, для яких запит безпеки повернув ІСТИНА – користувач побачить, а решта – ні.
Права 1С, на які встановлені обмеження RLS 1С, підсвічені сірим.

Копіювання тих самих налаштувань RLS 1С робиться за допомогою шаблонів. Ви робите шаблон, називаєте його (наприклад) Мій Шаблон, у ньому вказуєте запит безпеки. Далі, в налаштуваннях права доступу 1С вказуєте ім'я шаблону так: «#МойШаблон».

Під час роботи користувача в режимі 1С Підприємство, при роботі RLS 1С, може з'являтися повідомлення про помилку «Недостатньо прав» (наприклад, на читання довідника Ххх).

Це означає, що RLS 1С заблокувала читання кількох записів.

Для того, щоб такого повідомлення не з'являлося, необхідно в тексті запиту вбудованою мовою 1С використовувати слово ДОЗВОЛЕНЕ ().

Наприклад:

Об'єкт конфігурації "роль" дає набір прав на операції (дії) над об'єктами конфігурації.

Роль "Повні права".

Це лише роль (не зумовлена), у якій встановлено прапорці попри всі види прав попри всі об'єкти зміни.

Відмінність її з інших ролей – наявність права «Адміністрування».

У разі створення хоча б одного користувача система починає перевіряти наявність права «Адміністрування» — воно має бути мінімум у одного користувача.

Обмеження доступу на рівні записів

Row Level Security (RLS) – обмеження лише на рівні записів.

Механізм обмежень доступу до даних дозволяє керувати правами доступу як на рівні об'єктів метаданих, а й лише на рівні об'єктів бази даних. Для обмеження доступу до даних можуть бути використані такі об'єкти:

  • ролі,
  • параметри сеансу,
  • функціональні опції,
  • привілейовані загальні модулі,
  • ключове слово Дозволено в мові запитів.

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

Технічна реалізація обмежень доступу до 1С

1С формує запит до СУБД. Кластер серверів додає до запиту секцію ДЕ, в якій міститься текст умови на обмеження доступу RLS, потім цей запит відправляється в СУБД, вилучені дані повертаються на клієнт 1С.


Такий механізм працюватиме за будь-якого запиту з клієнта:

  • у звітах,
  • у динамічних списках та у звичайних формах списків
  • у довільних запитах.

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

Шляхи обходу обмежень доступу.

У великих ресурсомістких операціях (обробки перепроведення документів, наприклад) частину коду можна виносити у привілейовані модулі.

а) Привілейований модуль — це загальний модуль із прапором «Привілейований» у властивостях.

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


Б) Також привілейованийрежим можна увімкнути для модулів об'єктів документів. Це робиться у властивостях документа, прапор

  • Привілейований режим під час проведення
  • Привілейований режим при скасуванні проведення


В) Метод ВстановитиПривілейованийРежим()

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

З наступного рядка коду діятиме привілейований режим виконання.

Діятиме він до рядка відключення цього режиму або до кінця процедури/функції

(Істина);

// Будь-який код тут буде виконаний без контролю прав та RLS

УстановитиПривілейованийРежим(Брехня); // або кінець процедури/функції

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

Якщо у процедурі або функції викликів методу УстановитиПривілейованийРежим(Брехня ) зроблено більше, ніж викликів методу УстановитиПривілейованийРежим(Істина), то буде викликано виняток

Функція Привілейований режим() повертає Істина , якщо привілейований режим ще увімкнено, і Брехня , якщо він повністю вимкнений. При цьому не аналізується кількість установок привілейованого режиму конкретної функції.

Усі викликані процедури та функції також виконуватимуться у привілейованому режимі.


Також є можливість стартувати привілейований сеанс. Це сеанс, у якому привілейований режим встановлено від початку роботи системи. При цьому під час роботи метод Привілейований режим() завжди буде повертати Істина , а можливість відключити привілейований режим не підтримується. Стартувати привілейований сеанс може лише користувач, якому доступні адміністративні права (право адміністрування). Запустити сеанс можна за допомогою ключа командного рядка запуску клієнтської програми UsePrivilegedMode або параметра рядка з'єднання з інформаційною базою prmod .


Закономірно виникає питання: Навіщо тоді взагалі налаштовувати обмеження доступу, якщо його можна легко обійти?

Безпечний режим.

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

ВстановитиБезпечнийРежим().

Безпечний режим також ігнорує привілейований режим.

Його потрібно встановлювати перед програмним викликом зовнішніх обробок або експортних процедур та функцій із їх модулів.

Під час виконання заборонених операцій під час виконання генерує виняток.

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

Налаштування обмеження доступу

RLS можна налаштувати лише для прав:

  • читання (select)
  • додавання (insert)
  • зміна (update)
  • видалення (delete)

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

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

Для операції зміниобмеження доступу до даних має відповідати об'єкт як до зміни (щоб об'єкт було прочитано), так і після зміни (щоб об'єкт було записано).

Для решти прав такої можливості немає.

Додамо нове обмеження права «читання» довідника «Номенклатура». Відкриється список полів, для яких можна налаштувати обмеження, що додається.

Це означає, що при спробі отримати доступ до позначених прапорцями полів обмеження спрацює, а при спробі отримати доступ до невідзначених полів обмеження не спрацює.

Якщо вибрати прапор « Інші поля», обмеження буде налаштовано для всіх полів таблиці, крім полів, для яких обмеження задані явно.


*Особливість: для прав додавання, зміна, видалення:

  • Обмеження може бути налаштовано лише для всіх полів.
  • Обмеження може лише одне.

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

В обмеженнях на об'єкти бази даних таких типів можуть бути використані не всі поля основного об'єкта даних обмеження:

  • у регістрах накопичення обмеження доступу можуть містити лише вимірювання основного об'єкта обмеження;
  • у регістрах бухгалтерії в обмеженнях можна використовувати лише балансові виміри основного об'єкта обмеження

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

Механізм накладання обмежень доступу.

Будь-яка операція над даними, що зберігаються в базі даних, в «1С:Підприємстві» зрештою призводить до звернення до бази даних з деяким запитом на читання або зміну даних. У процесі виконання запитів до бази даних внутрішні механізми «1С:Підприємства» виконують обмеження доступу. При цьому:

  • Формується список прав(читання, додавання, зміна, видалення), список таблиць бази даних та список полів, які використовуються цим запитом.
  • З усіх ролей поточного користувача вибираються обмеження доступудо даних всім прав, таблиць і полів, задіяних у запиті. При цьому якщо якась роль не містить обмежень доступу до даних якоїсь таблиці або поля, то це означає, що в цій таблиці доступні значення необхідних полів з будь-якого запису. Інакше висловлюючись, відсутність обмеження доступу до даних означає наявність обмеження ДЕ Істина .
  • Отримуються поточні значення всіх параметрів сеансу та функціональних опцій, що беруть участь у вибраних обмеженнях.

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

Обмеження, отримані з однієї ролі, поєднуються операцією І .

Обмеження, отримані з різних ролей, поєднуються операцією АБО .

Побудовані умови додаються до SQL-запитів, із якими «1С: Підприємство» звертається до СУБД. При зверненні до даних умов обмеження доступу перевірка прав не виконується (ні до об'єктів метаданих, ні до об'єктів бази даних). Причому механізм додавання умов залежить від обраного способу дії обмежень "все" або "дозволені".


*Особливість: Якщо користувачеві доступні кілька ролей з налаштованими обмеженнями на рівні записів до одного об'єкта, то умови обмежень складаються логічною операцією «АБО». Тобто повноваження користувача складаються.

Звідси випливає слід висновок: не допускати перетину умови обмеження доступу одного об'єкту у різних ролях, т.к у разі сильно ускладниться текст запиту і це вплине на продуктивність.

Спосіб "Все".

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

Накладення обмежень доступу способом «все» схематично представлено малюнку:


Спосіб «Дозволені».

При накладенні обмежень способом «дозволені» до SQL-запитів додаються такі умови, щоб заборонені поточному користувачеві записи не впливали на результат запиту. Інакше висловлюючись, при накладення обмежень у режимі «дозволені» заборонені даному користувачеві записи вважаються відсутніми і результат операції не впливають, що схематично представлено малюнку:


Обмеження доступу до даних накладаються на об'єкти бази даних у момент звернення «1С:Підприємства» до бази даних.

У клієнт-серверному варіанті «1С:Підприємства» накладення обмежень виконується на сервері «1С:Підприємства».

Однак ця опція (Дозвіл) не спрацює у випадку, якщо ми в запиті звернемося до таблиці, для якої не налаштовані обмеження доступу, але в якій є посилання на рядки таблиці з налаштованими обмеженнями. У цьому випадку результат запиту видасть<Объект не найден>…...» замість значення поля посилання.


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

У разі об'єктного читання даних із бази немає можливості поставити прапор «Дозволені». Тому потрібно настроювати відбори для об'єктного читання з урахуванням можливих обмежень прав доступудля користувача. Засобів отримання лише дозволених даних в об'єктній техніці не передбачено.

Важливо, що якщо у запиті не вказано ключове слово ДОЗВОЛЕНІ, всі відбори, задані у цьому запиті, не повинні суперечити жодному з обмежень на читання об'єктів бази даних, що використовуються в запиті. При цьому якщо у запиті використовуються віртуальні таблиці, то відповідні відбори мають бути накладені і самі віртуальні таблиці.

Практика 1. Конструктор запитів у налаштуваннях RLS.

Складемо текст секції «ДЕ» у запиті до довідника. Можна скористатися конструктором запитів.
Конструктор має урізаний вигляд.


Закладка «Таблиці»

Основна таблиця буде таблицею об'єкта, котрій налаштовується обмеження.

Можна також вибирати інші таблиці та налаштовувати між ними різні зв'язки на закладці «Зв'язки».

Закладка «Умови»

Тут налаштовуються власне умови обмеження доступу

Додамо умови на реквізит "Ціна" довідника номенклатура для права на "читання" до всіх полів таблиці.

Номенклатура ДЕ Номенклатура.Ціна > 500

Перевіримо, як спрацює це просте правило. Таблиця довідника містить такі елементи:


Після налаштування обмеження доступу таблиця покаже лише елементи, які відповідають умові:


Зникли також групи. Змінимо текст обмеження

«Номенклатура ДЕ Номенклатура.Ціна > 500

АБО Номенклатура.ЦеГрупа»

Ну ось тепер те, що потрібне.


Якщо в налаштуванні списку прибрати відображення поля код, будуть виведені всі елементи довідника, тобто. обмеження не спрацювало. Якщо встановити поле «Код», обмеження буде працювати.


Незважаючи на те, що елемент довідника видно в полі списку, його форму не можна буде відкрити, тому що налаштовано обмеження на реквізит. Те саме у довільному запиті: при спробі отримати «обмежений» реквізит, буде помилка доступу.


Якщо спробувати отримати обмежений реквізит програмним чином, також буде викликана помилка доступу.


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

Тому при програмній роботі з об'єктами БД потрібно мати на увазі можливі обмеження на рівні записів та отримувати всі потрібні дані об'єкта запитом і потім поміщати їх у структуру або виконувати частину коду у привілейованому модулі.

Після налаштування обмеження доступу змінилося відображення рядка у списку прав – вона стала сірою та з'явилася піктограма.

Обмеження для налаштування доступу (RLS).

  • Немає секції Підсумки;
  • Не можна звертатися до віртуальних таблиць регістрів;
  • У певному вигляді не можна використовувати параметри;
  • У вкладених запитах можуть використовуватись будь-які>/span> засоби мови запитів, крім :
    • оператора В ІЄРАРХІЇ;
    • пропозиції ПІДСУМКИ;
    • результати вкладених запитів не повинні містити табличні частини;
    • віртуальних таблиць, зокрема ЗалишкиІОбороти

Практика 2. Номенклатура із актуальною ціною.

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

Рішення:

Додаємо нове правило обмеження доступу довіднику «Номенклатура» на право «читання».
Вибираємо "інші поля".
У конструкторі додаємо вкладений запит. У ньому вибираємо таблицю регістру відомостей «Ціни номенклатури».
Вкладки "порядок" немає - це особливість конструктора запитів для побудови обмеження доступу.
На вкладці "Додатково" ставимо "перші 999999999", вкладка "порядок" з'явилася.
Налаштовуємо впорядкування по полю «Період» за спаданням.
Потім налаштовуємо зв'язок основної таблиці із вкладеним запитом на посилання.


Шаблони обмежень доступу.

Практика 3. Обмеження на «контрагенти» за значенням у константі.

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

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

Рішення

Для довідника «Контрагенти» для права «читання» налаштуємо обмеження, додавши до секції «Умови» вкладений запит до константи. Не забути ЦеГрупа.

Бачимо проблему, довідник Контрагенти фільтрується правильно, а документи з реквізитом "Контрагент" відображаються всі, деякі з "битими" посиланнями в реквізиті "Контрагент".

Тепер потрібно налаштувати обмеження доступу для всіх об'єктів, які використовують посилання на «Контрагенти». Знайдемо їх сервісом "пошук посилань на об'єкт".

Скопіюємо та трохи доопрацюємо текст умови RLS із довідника «Контрагенти». Це потрібно зробити стільки разів, скільки знайдено об'єкти.

Або використовувати шаблон обмежень доступу, щоб уникнути проблем дублювання коду.

Шаблони обмежень доступу налаштовуються на рівні ролі і можуть використовуватися для будь-якого об'єкта в рамках редагованої ролі.

Можна винести у шаблон будь-який шматок тексту обмеження доступу. Виклик шаблону здійснюється через символ #. Наприклад, #ШаблонКонтрагент.

Через # у 1С пишуться інструкції препроцесору. У контексті параметрів обмежень доступу платформа замінює текст виклику шаблону на текст шаблону.

Винесемо в шаблон «ШаблонКонтрагент» текст після слова ДЕ, окрім тексту про ЕтоГрупа.

Параметри шаблонів обмежень доступу.

Продовжимо розв'язання задачі 2.

Проблема полягає в тому, що основна таблиця в довіднику називається «контрагент», у документі «Прибуткова накладна». Перевірене поле у ​​довіднику називається «посилання», у документі – «Контрагент».

Змінимо в тексті шаблону назву основної таблиці на "#Поточна Таблиця"

"#Поточна Таблиця" - це зумовлений параметр.

І через точку вкажемо номер вхідного параметра - ". # Параметр (1)

"# Параметр" - це теж зумовлене значення. Може містити кількість вхідних параметрів. Звернення до них відбувається за порядковим номером.

У тексті обмеження доступу довіднику вкажемо наступне:

Для документа наступне:

«Реалізація Товарів ДЕ #ШаблонКонтрагент(«Контрагент»)»

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

Основна таблиця - Номенклатура

Текст шаблону такий:

#ПоточнаТаблиця ДЕ #ПоточнаТаблиця.#Параметр(1) = #Параметр(2)

Текст шаблону містить частину тексту мовою обмеження доступу до даних і може містити параметри, які виділяються символом «#» .

Після символу "#" можуть слідувати:

  • Одне з ключових слів:
    • Параметр, після якого в дужках вказується номер параметра шаблону;
    • Поточна Таблиця – позначає вставку у текст повного імені таблиці, на яку будується обмеження;
    • Ім'яПоточноїТаблиці– означає вставку в текст повного імені таблиці (як рядкове значення, у лапках), до якої застосовується інструкція, на поточному варіанті вбудованої мови;
    • Ім'яПоточногоПраваДоступу– містить ім'я права, для якого виконується поточне обмеження: ЧИТАННЯ/READ, ДОДАВАННЯ/INSERT, ЗМІНА/UPDATE, ВИДАЛЕННЯ/DELETE;
  • ім'я параметра шаблону означає вставку в текст обмеження відповідного параметра шаблону;
  • символ «#» – вставляє текст одного символу «#» .

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

  • Шаблон обмеження доступу, який вказується у форматі #Ім'я Шаблона(«Значення параметра шаблону 1», «Значення параметра шаблону 2»,...). Кожен параметр шаблону полягає у подвійні лапки. При необхідності вказати в тексті параметра символу подвійної лапки слід використовувати дві подвійні лапки.
  • Функція СтрУмістить(ДеШукаємо, ЩоШукаємо). Функція призначена для пошуку входження рядка ЩоШукаємо в рядку ДеДищем. Повертає Істина у випадку, якщо входження виявлено і Брехня – інакше.
  • Оператор для конкатенації рядків.

Для зручності редагування тексту шаблону на закладці Шаблони обмежень у формі ролі потрібно натиснути кнопку Встановити текст шаблону. У діалозі, що відкрився, ввести текст шаблону і натиснути кнопку ОК.

Їх не можна встановити методом ВстановитиПараметр()або чимось подібним.

Як параметри в даному випадку виступають:

  • Параметри сеансу
  • Функціональні опції

Читання параметрів сеансу у запиті на обмеження доступу відбувається у привілейованому режимі, тобто без контролю прав на операції з ними.

Практика 4. Доступ до «своїх» контрагентів

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

Є довідник "Користувачі", довідник "Контрагенти", документи з реквізитом "Контрагент".

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

Зв'язок також потрібно налаштувати.

Можливі варіанти:

Встановлення зв'язків користувач + контрагент

  • Реквізит у довіднику контрагенти
  • Реєстр відомостей

Можливі рішення задачі:

  • Зберігати користувача у константі – поганий варіант, константа доступна всім користувачам.
  • Зберігати у параметрах сеансу фіксований масив контрагентів поточного користувача – не дуже хороший варіант, контрагентів може бути багато
  • Зберігати у параметрах сеансу поточного користувача, а потім запитом отримувати список «його» контрагентів – прийнятний варіант.
  • Інші варіанти.

Рішення.

Створимо новий параметр сеансу «Поточний Користувач» та пропишемо його заповнення у модулі сеансу.

Створимо регістр відомостей «Відповідність менеджерів та контрагентів»

Створимо нову роль і в ній нове обмеження доступу документа «ПрибутковаНакладна».

У тексті запиту з'єднаємо основну таблицю з регістром відомостей по Контрагент = Контрагент і Менеджер = Поточний Користувач. Вид з'єднання Внутрішнє.

По можливості краще уникати вкладених запитів у текстах обмеження доступу, оскільки він виконуватиметься при кожному читанні даних із цього об'єкта з БД.

Перевіряємо – обмеження працюють

*Особливість : Якщо змінити список контрагентів користувача в регістрі обмеження доступу діятимуть відразу без перезапуску сеансу користувача.

Практика 5. Дата заборони змін.

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

Створимо регістр відомостей «ДатиЗаборониЗмін» з виміром Користувач, ресурс ДатаЗаборони.

Побудуємо логіку рішення таким чином:

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

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

  • Документи
  • Періодичні регістри відомостей

Створимо нову роль «Ораніння ПоДаті Заборони Змін».

У ній для документа «ПрибутковаНакладна» для права «зміна» додамо нове обмеження доступу.

Налаштування вказуємо всім полів.

Текст обмеження такий:

ПрибутковаНакладна З Документ.ПриходнаНакладна ЯК ПрибутковаНакладна

ДатиЗаборониЗмін.ДатаЗаборони ЯК ДатаЗаборони
З

ВНУТРІШНЯ З'ЄДНАННЯ (ВИБРАТИ
МАКСИМУМ(ДатиЗаборониЗмін.Користувач) ЯК Користувач
З
РеєстрВідомостей.ДатиЗаборониЗмін ЯК ДатиЗаборониЗмін
ДЕ
(ДатиЗаборониЗмін.Користувач = &ПоточнийКористувач
АБО ДатиЗаборониЗмін.Користувач = ЗНАЧЕННЯ(Довідник.користувачі.ПустаПосилання))) ЯК ВЗ_Користувач
ПЗ ДатиЗаборониЗмін.Користувач = ВЗ_Користувач.ЯК ВкладенийЗапит
ПЗ ПрибутковаНакладна.Дата > ВкладенийЗапрос.ДатаЗаборона

Перевіряємо – обмеження працює.

Використання інструкцій препроцесору

#Якщо Умова1 #Тоді

Фрагмент запиту 1

#ІнакшеЯкщо Умова2 #Тоді

Фрагмент запиту 2

#Інакше

Фрагмент запиту 3

#КінецьЯкщо

В умовах можна використовувати логічні операції (і. або, не тощо) та звернення до параметрів сеансу.

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

Мінус полягає в тому, що конструктор запиту з таким текстом не працюватиме.

*Особливість:

На відміну від інструкцій препроцесору вбудованої мови в текстах обмеження доступу перед оператором. Тоді потрібно ставити решітку — #

Практика 6. Перемикач «Використовувати RLS»

Доповнимо нашу систему обмежень перемикачем, який включає/вимикає використання обмеження на рівні записів.

Для цього додамо Константу та параметр сеансу з ім'ям «Використовувати RLS».

Пропишемо в Модулі сеансу встановлення значення параметра сеансу значення константи.

Додамо до всіх текстів обмеження доступу такий код:

«#Якщо &ВикористовуватиRLS #Тоді ….. #КінецьЯкщо»

Перевіряємо – все працює.

Проте, тепер після включення прапора «використовувати РЛС» зміни одразу не набудуть чинності. Чому?

Тому що параметр сеансу встановлюється під час запуску сеансу.

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


Кінець першої частини.

Платформа 1С: Підприємство 8 має гострий механізм обмеження доступу до даних на рівні записів. Загальні відомості про нього Ви можете прочитати тут. Якщо коротко, то RLS дозволять обмежити доступ до даних за деякими умовами значення полів. Наприклад, можна обмежити доступ користувачів до документів залежно від значення реквізиту "Організація". Деякі користувачі будуть працювати з документами з організації "Керуюча компанія", а інші з організацією "Молочний завод". Як приклад.

Підготовка

Приклад реалізуємо в конфігурації демонстраційної УПП 1.3. Створимо користувача "Комірник" і додамо йому однойменну роль "Комірник".

Тепер приступимо безпосередньо до налаштування прав доступу на рівні записів. Переключимося на інтерфейс "Адміністрування користувачеві". У головному меню оберемо "Доступ на рівні записів -> Параметри". Тут відзначимо галкою "Обмежити доступ лише на рівні записів за видами об'єктів", а списку об'єктів оберемо "Организации".

Тим самим ми увімкнули використання RLS. Тепер потрібно його налаштувати.

Розмежування доступу на рівні записів налаштовується окремо для кожного користувача або профілів повноважень. RLS налаштовується для користувачів. Додамо нову групу користувачів, назвемо її "Комірники"

Склад групи праворуч на формі показує список користувачів, що належать до цієї групи. Додамо до складу створеного нами користувача. Ліворуч таблиця обмежень доступу. У налаштування RLS ми вибрали, що доступ буде розмежовуватись тільки по організаціях, тому ми бачимо лише один вид об'єкта доступу. Натисніть кнопку "Налаштування доступу". Відкриється обробка параметрів прав доступу для поточної групи.

До списку об'єктів доступу для групи додамо організацію "ІПП "Підприємець"". Вид наслідування прав залишимо без змін. Право на об'єкт доступу встановимо для читання та запису. Натисніть "ОК", налаштування готові. Ми тільки-но налаштували RLS на рівні організацій.

Що бачить користувач

Запустимо програму під створеним раніше користувачем та відкриємо довідник "Організації". Ось так буде виглядати список для нашого користувача та користувача з повними правами:

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

Таким чином, користувач не тільки не побачить організації, доступ на які не встановлений для нього, але й не зможе прочитати/записати документи та інші об'єкти в інформаційній базі, на які встановлені права на роль на реквізит "Організація".

Ми розглянули найпростіший приклад налаштування RLS. У наступній статті поговоримо про реалізацію механізму RLS у конфігурації "Управління виробничим підприємством" версії 1.3.

Настроювання доступу на рівні записів довідників.

Ця настройка в конфігурацію була включена не так давно, я особисто вважаю, що налаштування дуже корисне.

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

Пропоную розглянути приклад з прикладу конфігурації УПП.

  1. На цьому етапі необхідно визначити набір груп користувачів.

Адміністратори;

Менеджери з продажу;

Менеджери закупівель;

  1. З другого краю етапі визначаються групи доступу до довіднику.

Покупці;

Постачальники;

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

Тепер необхідно описати власне ті параметри, які потрібно виконати в 1С.

  1. Включимо "Обмежений доступ на рівні записів". Сервіс - керування користувачами та доступом - Параметри доступу на рівні записів. рис. 1.

Відкриється форма обробки "Параметри доступу на рівні записів" див. Мал. 2.

На цій формі необхідно власне включити обмеження, за що відповідає прапор «Обмежити доступ на рівні записів за видами об'єктів» і вибрати довідники, за якими обмеження діятиме. У цій статті розглядається лише довідник «Контрагенти».

  1. Далі нам стануть у нагоді ті групи користувачів та контрагентів, які були визначені на початку статті.

Групи контрагентів вводяться у довіднику «Групи користувачів» див. 3.

Відкриється форма елемента довідника "Групи користувачів" див. Мал. 4.

У лівій частині вікна вказується об'єкт доступу (у нас це «контрагенти»), праворуч вказуються користувачі, які входять до групи, у цьому прикладі це «Адміністратори».

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

  1. На третьому кроці потрібно ввести "групи доступу контрагентів", за це відповідає довідник "Групи доступу контрагентів". рис. 5.

Для нашого прикладу це: Покупці, Постачальники та інші. Див. Рис. 6.

  1. На цьому етапі потрібно призначити групу доступу, кожному елементу довідника «контрагенти». Див. Рис. 7.

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

  1. Цей етап є кульмінаційним етапом. На цьому етапі налаштовується доступ "груп користувачів" до "груп доступу контрагентів" налаштовується це за допомогою обробки "Налаштування прав доступу на рівні записів" див. 8.

Червоним кольором виділено відношення груп користувачів до груп доступу контрагентів. Для груп «Менеджери закупівлі» та «Менеджери продажів» налаштовуються відносини так само, тільки об'єкти доступу вказуються ті до яких вони повинні мати доступ, наприклад, тільки «Постачальники» або лише «Покупці». Прапори, наприклад «Видимість у списку», це права «Об'єкта доступу». З назви я думаю, що зрозуміла й функціональність цих прав.

Після зазначених вище маніпуляцій у Вас повинен з'явитися розмежований доступ до довідника «Контрагенти».

За аналогією налаштовуються та інші довідники.

Важливо:

Розмежований доступ не поширюється на роль «Повні права»;

У наборі ролей користувача має бути роль «Користувач»;

Якщо у Вас власні ролі, то необхідно у вашу роль вставити шаблони та обмеження як у ролі «Користувач» по відношенню до довідника «Контрагенти» (див. код у ролі Користувач клацнувши на довіднику контрагенти).

 

 
Це цікаво: