Права доступу
Рівні доступу
Рівень доступу у Смереці – річ дуже проста. Це число від 0 до 255, яке визначає ступінь секретності даної вершини. Користувач може побачити вершину тільки в тому випадку, якщо його рівень доступу є не меншим, ніж рівень доступу вершини. Рівень доступу користувача визначається тією групою, до якої він належить. Рівень доступу вершин визначається редактором сайту і зберігається в атрибуті accesslevel вершини.
Анонімному користувачу з Інтернету за умовчанням надається рівень доступу 5. Отже, сторінки з рівнями доступу 0..5 є загальновидимими.
Логіка секретності підказує, що рівні доступу мають збільшувались від кореня дерева до термінальних вершин. Тобто найбільш секретні сторінки мусять бути найглибше занурені в дерево, мати найвищі ієрархічні рівні. Тим не менше з певних міркувань сайт може мати «острови» сторінок публічного доступу, підпорядковані секретним вершинам. Такі сторінки виступають як напівсекретні – якщо користувач знає їхні URL, він може їх побачити, але вони не доступні через стандартні навігаційні механізми Смереки.
Конструктор сторінок Смереки мусить сам вирішувати, чи сповіщати користувача про наявність підпорядкованих сторінок з вищим рівнем доступу. Таке сповіщення може бути корисним, наприклад, для організації платного доступу до інформації.
Призначення рівнів доступу
При додаванні нової вершини вона автоматично набуває рівень доступу вершини-господині. Часто це саме те, що треба.
Звичайно, редактор не може задати для вершини рівень доступу вищий за той, який має він сам (тобто не може сховати вершину від себе самого).
Блокування доступу
Адміністратор Смереки може визначити, що має відбуватись у випадку, якщо користувач не має прав доступу до веб-сторінки. Реакція визначається атрибутом AccessBlock для субдомену, в контексті якого відбулося блокування. Передустановлені значення :
403 – віддати код 403 (Forbidden) згідно визначення HTTP протоколу і сформувати сторінку з поясненням причини відмови. Така відповідь означає, що Смерека визнає існування сторінки. Це значення вживається за умовчанням.
404 – віддати код 404 (Not found) згідно визначення HTTP протоколу і сформувати сторінку з повідомленням, що сторінки не існує. Така відповідь означає, що Смерека заперечує існування сторінки (це може бути придатнішим для секретних сторінок, само існування яких є секретним).
Custom – буде викликано функцію CustomAccessBlocking. Ця функція має сформувати відповідну реакцію на виявлену ситуацію. За умовчанням вона повертає код 403.
Silent – здійснити внутрішнє перенаправлення на кореневу сторінку субдомену (оптимально для випадку, коли не варто лякати користувача повідомленнями про помилки).
Права користувачів
Анонімний користувач за умовчанням має тільки одне право – переглядати доступні йому сторінки сайту, використовуючи ту функціональність, яку вони надають (наприклад, купуючи щось в інтернет-магазині чи надсилаючи повідомлення через форму зворотнього зв’язку).
Зареєстрований користувач набуває права, які визначені в групі, до якої він належить (точніше, до якої належить його обліковий запис). Він завжди має право перегляду сторінок з рівнем доступу 0..$MaxPublicLevel. Всі інші права (додавати / змінювати / видаляти щось і т.д.) діють тільки в межах зони впливу групи.
Група – це вершина спеціального класу, призначена для управління правами доступу. Групи утворюють окрему ієрархію Смереки. Група може містити інші групи, користувачів та посилання на зони адміністрування. Зоною впливу групи є сукупність зон адміністрування. Група, яка не містить жодної зони адміністрування, не має впливу (в прямому і переносному значеннях) : члени такої групи не мають вершин БД, до яких вони можуть застосувати свої права.
Ієрархія груп починається з групи глобальних адміністраторів (за умовчанням вона має ім’я Administrators). Ця група надає користувачам усі права, які тільки існують у Смереці. За умовчанням у цій групі створюється один користувач з іменем Admin і одна зона адміністрування, яка охоплює все дерево вершин сайту. Тому-то членство в цій групі дає право управляти всіма об’єктами Смереки.
Адміністратором у Смереці називається кожен користувач, який має права додавати / знищувати / змінювати об’єкти адміністрування, тобто групи, користувачів і зони. Область адміністрування поширюється на всі об’єкти тієї групи, до якої належить адміністратор, і на всі підпорядковані об’єкти. Адміністратор має право переглядати властивості своєї групи, але не має права їх змінювати – для цього потрібно втручання адміністратора вищого рівня. З цього випливає, що властивості групи глобальних адміністраторів не можуть бути змінені (і не треба !).
Маючи відповідні права, адміністратор може створювати нові групи, підпорядковані своїй групі, і делегувати їм права. Загальне правило полягає в тому, що адміністратор не може делегувати більше прав, ніж має сам, але може зменшити обсяг прав. Таким чином, права груп звужуються по мірі віддалення від групи глобальних адміністраторів. Але слід розуміти, що група не успадковує від групи-господині ніяких властивостей. Зокрема, зона впливу визначається для кожної групи осібно.
Визначаючи права груп, адміністратор мусить пам’ятати, що у Смереці право CanModify* є важливішим за права CanCreate* та CanDelete*. Користувач повинен отримати право змінювати відповідні об’єкти, щоб потрапити в редактор цих об’єктів, де лежать команди створення / видалення.
Зони адміністрування
Зона адміністрування створюється з будь-якої вершини дерева Смереки додаванням двох атрибутів ZoneId, ZoneMask. Ці атрибути є схованими і недоступними для редакторів вершин. Їх можуть бачити тільки ті адміністратори, які мають права над зонами. Зоною є крона такої вершини.
Всередині зони адміністрування можна створювати інші зони адміністрування за умови, що ключі цих зон будуть відповідати масці зони-господині (тобто ZoneId AND (NOT ParentZoneMask) == ParentZoneId). Ясно, що зона з нульовою маскою (термінальна зона) вже не може мати вкладених зон.
За умовчанням створюється тільки одна зона адміністрування. Вона асоційована з кореневою вершиною ієрархії Смереки і має ZoneId = 0, ZoneMask = 0xFFFFFFFF, тобто поглинає всі інші зони адміністрування.
Управління зонами є досить складною операцією, яка потребує чіткого планування і ясного усвідомлення можливих побічних наслідків.
Створення нової зони можливе скрізь, окрім термінальної зони. Ключ нової зони мусить відповідати масці діючої в даному контексті зони. Після створення нова зона захоплює всю крону своєї базової вершини. Якщо при цьому захопленні зустрічаються вкладені зони, вони залишаються незмінними за умови, що вони відповідають масці новостворюваної зони; в противному випадку ці зони видаляються, і належні до них вершини включаються в новостворювану зону. Оце каскадне видалення зон може мати небажані наслідки для груп, які використовували ці зони.
При видаленні зони належні до неї вершини приєднується до зони-господині. Вкладені зони залишаються незмінними.
При зміні налаштувань зони застосовується алгоритм створення нової зони з новими параметрами. Отже, розширення маски зони є безпечним, її звуження – потенційно небезпечним, а зміна ключа – безумовно небезпечним. Розглянемо це на прикладах.
Початковий стан | Новий стан | Наслідки |
ZoneId = 0x11223300 ZoneMask = 0x000000FF |
ZoneId = 0x11223000 ZoneMask = 0x00000FFF |
Розширення маски (безпечно); вкладені зони залишаються незмінними. |
ZoneMask = 0x0000000F |
Звуження маски; всі зони з ключами 0x11223310..0x112233FF будуть видалені, залишаться тільки зони 0x11223300..0x1122330F. |
|
ZoneId = 0x11223400 | Зміна ключа. Всі вкладені зони будуть видалені. |