Списки контролю доступу
Списки контролю доступу (ACL) можна використовувати для надання певним користувачам чи групам прав на виконання певних дій. Вони використовуються для:
- приховування деяких сторінок від публічного доступу.
- публікації лише деяких сторінок для публічного доступу.
- надання лише певним особам чи групі права на редагування однієї або кількох сторінок.
- дозволу чи заборони видалення сторінок.
- керування тим, хто може змінювати адміністративні правила сторінки.
Для використання ACL треба або мати доступ до конфігурації вікі (для встановлення глобальних ACL) або право admin на певну сторінку, на якій ви хочете встановити (або змінити) ACL.
1. Зміст
Contents
2. Основи
Наявні права ACL:
- read - хто може переглядати сторінку
- write - хто може редагувати сторінку
- delete - хто може видаляти сторінку
- revert - что може повертати сторінку до попередньої версії
- admin - хто може змінювати рядок "#acl" на сторінці.
Використовувати ACL у моін дуже просто, треба додати керуючий рядок згори сторінки, наприклад такий:
#acl ПевнийКористувач:read,write All:read
![/!\](/moin_static1911/modernized/img/alert.png "/!\")
Ви вже повинні мати право `admin`, щоб мати змогу додавати чи змінювати цей рядок acl - перегляньте сторінки ДовідкаКонфігурування та ДовідкаАвтоАдміністрування.
Цей рядок дозволяє користувачу `ПевнийКористувач` переглядати та редагувати цю сторінку, усі інші зможуть лише переглядати її, але не редагувати (якщо ви не встановили для цього спеціальні параметри у конфігурації сайту).
При роботі системи моін вікі вкладення також захищаються ACL записом сторінки, до якої вони належать.
Вкладення не захищаються, якщо на сервері налаштовано прямий доступ до вкладень (тобто, коли параметр використовується параметр `attachments` у файлі wikiconfig.py).
3. Конфігурація
Для налаштовування ACL на сайті моін є наступні конфігураційні параметри.
Параметр |
Типове значення |
Опис |
acl_rights_before |
u"" |
застосовується перед сторінкою чи типовими ACL |
acl_rights_after |
u"" |
застосовується після сторінки чи типових ACL |
acl_rights_default |
u"Trusted:read,write,delete,revert \ |
застосовується лише коли не вказано інших ACL на сторінці, до якої надається доступ |
acl_rights_valid |
`["read", ` `"write", ` `"delete", ` `"revert", ` `"admin"]` |
це - допустимі (відомі) права (за необхідності, їх список можна розширити). |
acl_hierarchic |
False |
Дозволяє ієрархічну обробку ACL, дивіться #ієрархія |
Тепер ви знаєте що вони роблять, але ж що вони означають?
"перед" означає примусове застосування (оскільки використовується алгоритм першої відповідності) Використовуйте цей параметр для адміністраторів загальних сторінок сайту або редакторів сторінок.
"типове значення" означає що робити, якщо на сторінці не вказано ACL. Це еквівалентно додаванню таких самих ACL безпосередньо до сторінки. Також є права, що об'єднуються, якщо типове значення записано серед ACL на сторінці.
"після" означає правила які треба не забути випадково (наприклад, надати усім доступ для перегляду)
Можна розглядати їх як обробку перед, серед, та після основних ACL сторінки.
Нотація u"" у рядках конфігурації означає unicode та має бути вказана - докладніше про це дивіться на сторінці ДовідкаКонфігурування.
Якщо для визначення груп ви не використовуєте назви у стилі ГорбатийРегістр, наприклад, для PROJECTGroup слід змінити page_group_regex на u'[a-z0-9,A-Z]Group$'
4. Синтаксис
Кожен рядок має такий синтаксис:
#acl [+-]Користувач[,Група,...]:[право[,право,...]] [[+-]ІншийКористувач:...] [[+-]Trusted:...] [[+-]Known:...] [[+-]All:...] [Default]
Де:
Користувач - ім'я користувача, права застосовуються лише для користувача з таким іменем.
Група - назва сторінки, що відповідає `page_group_regex` з деякими рядками у вигляді " * Member" (дивіться #Групи).
Trusted - спеціальна група, що містить усіх автентифікованих користувачів, з автентифікацією типу HTTP-Basic.
Known - спеціальна група, що містить усіх допустимих користувачів (подібно до використання cookie).
All - спеціальна група, що містить усіх користувачів (відомих та анонімних).
Default - спеціальний запис, що вставляє у вказаному місці записи з `acl_rights_default` (Дивіться #Default).
right може бути довільним словом, наприклад read, write, delete, revert, admin. Припустимі лише слова, що вказані у `acl_rights_valid`, інші ігноруються. У виразі можна не вказувати права, тоді права не надаються.
Не додавайте пробіл між назвою та правами - `All: write,read` - це некоректний рядок ACL.
5. Можливі права
Є певні права, які можна використовувати у записах ACL. Зверніть увагу, що DeletePage та RenamePage неприпустимі, якщо користувач не належить до `Known`, навіть якщо надано право `delete`.
- read
- Вказані користувачі матимуть змогу переглядати текст цієї сторінки.
- write
- Вказані користувачі матимуть змогу редагувати цю сторінку.
- delete
- Вказані користувачі матимуть змогу видаляти цю сторінку та її вкладення.
- revert
- Вказані користувачі матимуть змогу повертати цю сторінку до попередньої версії.
- admin
- Вказані користувачі матимуть адміністративні права на цю сторінку. Тобто вони зможуть змінювати її ACL, включно з надаванням та забиранням права "admin" у інших користувачів.
Немає окремого права rename: для перейменування потрібно щоб користувач мав права read, write та delete.
6. Логіка роботи на одній сторінці
Коли користувач намагається отримати доступ до певного, захищеного ACL ресурсу, то ACL обробляються у порядку їх появи. Перший ACL, що відповідає користувачу визначає чи матиме користувач доступ до цього ресурсу, обробка припиняється одразу при виявленні відповідності імені користувача у записі ACL.
Оскільки використовується алгоритм першої відповідності, вам слід сортувати ваші ACL: спочатку окремі імена користувачів, потім спеціальні групи, потім загальні групи, потім `Known` та зрештою `All`.
Наприклад, наступний ACL вказує, що `ПевнийКористувач` може переглядати та редагувати ресурси, що захищені цим ACL, а будь-який член групи `ПевнаГрупа` (окрім `ПевнийКористувач`, якщо він входить до цієї групи) має адміністративні права, а всі інші можуть лише переглядати ресурс.
#acl ПевнийКористувач:read,write ПевнаГрупа:read,write,admin All:read
Щоб зробити систему більш гнучкою, є два модифікатори: префікси '+' та '-'. При їх використанні обробка припиняється лише якщо певне право для певного користувача відповідає користувачу та праву у вказаному ACL, але продовжується, якщо ви шукаєте інше право (або іншого користувача). У випадку '+' право буде надане, у випадку '-' право буде заборонено (при зупинці обробки).
Наприклад, вважаємо що `ПевнийКористувач` є членом `ПевнаГрупа`, наведений вище ACL можна переписати так:
#acl -ПевнийКористувач:admin ПевнаГрупа:read,write,admin All:read
Цей приклад є специфічним для `ПевнийКористувач`,оскільки коли для користувача `ПевнийКористувач` запитується право admin, доступ буде заборонено та обробка припиняється. У іншому випадку, обробка продовжується.
Або навіть:
#acl +All:read -ПевнийКористувач:admin ПевнаГрупа:read,write,admin
`+All:read` означає що коли будь-який користувач запитує право read, він отримає доступ та обробка зупиняється. У іншому випадку обробка продовжується. Якщо право admin запитується для користувача `ПевнийКористувач`, доступ буде заборонено та обробка зупиняється. У іншому випадку обробка продовжується. Зрештою, якщо член групи `ПевнаГрупа` запитує деяке право, доступ надається, доступ надається якщо це право вказане, або не надається у іншому випадку. Усі інші користувачі не мають інших прав, окрім визначених у конфігурації.
Зверніть увагу, можливо, ви не захочете використовувати другий та третій приклади у записах ACL на сторінках. Хоча, вони дуже корисні у записах конфігурації сайтів.
7. Успадковування типових прав
Іноді може знадобитися надати комусь права без суттєвого впливу на типові права. Наприклад, уявімо, що у вашій конфігурації є наступні записи:
acl_rights_default = u"TrustedGroup:read,write,delete,revert All:read" acl_rights_before = u"AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin"
Тепер, є сторінка, до якої ви хочете надати доступ "write" для користувача `ПевнийКористувач`, але також бажаєте зберегти типову поведінку для All та `TrustedGroup`. Це можна легко зробити користуючись записом Default:
#acl ПевнийКористувач:read,write Default
Це призведе до додавання записів з `acl_rights_default` замість слова Default. Іншими словами, наведений вище запис еквівалентний наступному:
#acl ПевнийКористувач:read,write TrustedGroup:read,write,delete,revert All:read
Погляньте на перший приклад у цьому розділі:
acl_rights_before = u"AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin"
ACL обробляються у порядку розташування у "before", потім ACL "сторінки/default" а потім "after", "зліва направо".
обробка починається зліва у "before" з `AdminGroup:...` - тобто проводиться перевірка чи є ви членом групи адміністраторів. Якщо це так, ви отримуєте ці права (arwdr) та обробка ACL ПРИПИНЯЄТЬСЯ.
Якщо ви не є членом групи адміністраторів, обробка ACL продовжується з `+TrustedGroup:admin` - перевіряється чи є ви членом групи `TrustedGroup`.
Якщо є відповідність, ви отримуєте ці права (a) та - тепер поведінка дещо відрізняється, оскільки використовується модифікатор - обробка ACL ПРОДОВЖУЄТЬСЯ! Тож, якщо є відповідність іншому правилу для цієї групи або ваш користувач належить до `Known:` чи `All:` ви також отримуєте ці права.
Якщо відповідності немає, обробка ACL триває - оброблюються вказані у сторінці ACL (якщо вони є) або типові ACL (якщо на сторінці немає ACL) та зрештою ACL з виразу "after" .
Хоча вони представляють однакові речі, успадковування типових ACL маж перевагу над автоматичним внесенням будь-яких подальших змін до типових ACL.
8. Ієрархічна обробка ACL
Нова властивість у версії 1.6
Якщо ви увімкнули `acl_hierachic` (дивіться вище), тоді сторінки вважаються ієрархічними та на права доступу користувача можуть впливати права доступу, що встановлені на сторінках вищого рівня.
В двох словах, якщо права не визначені у поточній сторінці,тоді перевіряються ACL батьківської сторінки, а потім її батьківської сторінки, і так далі доки не залишиться батьківських сторінок.
Всі звичайні правила ACL обробляються як описано вище, але замість перевірки ACL лише з поточної сторінки, до рядків #acl зі сторінки додаються до усі ACL з кожної сторінки у ієрархії у напрямку до кореня. Розглянемо декілька прикладів для сторінок з назвами A/B/C/D, та відмінності при увімкненій та вимкненій функції:
acl_hierarchic |
Послідовність обробки |
false |
acl_rights_before, A/B/C/D, [acl_rights_default], acl_rights_after |
true |
acl_rights_before, A/B/C/D, A/B/C, A/B, A, [acl_rights_default], acl_rights_after |
Зверніть увагу, що acl_rights_before, acl_rights_default та acl_rights_after не застосовуються один раз до кожної сторінки у ієрархії, а лише один раз при обробці сторінок A/B/C/D. Стосовно типових прав, вони працюють як і раніше, але замість використання їх за відсутності ACL на поточній сторінці, вони використовуються якщо немає сторінок у ієрархії, що містять хоч якісь ACL. Тож насправді, ієрархічні ACL не роблять нічого іншого, як замінюють ACL поточної сторінки об'єднанням усіх рядків #acl, знайдених на сторінках ієрархії.
9. Групи
Групи користувачів спрощують вказування прав для великих груп. Зазвичай, назва сторінки групи закінчується на `Group` наприклад ДрузіGroup. Це дозволяє MoinMoin трактувати їх як список користувачів. Типовий шаблон можна змінити (наприклад для інших мов, тощо.), дивіться ДовідкаКонфігурування.
Лише друзі користувача `ПевнийКористувач` можуть читати та редагувати сторінку:
#acl ПевнийКористувач:read,write ПевнийКористувач/ДрузіGroup:read,write
`ПевнийКористувач/ДрузіGroup` буде сторінкою зі списком верхнього рівня, в якому перелічені імена користувачів вікі у цій групі:
#acl ПевнийКористувач:read,write,admin,delete,revert * JoeSmith * JoeDoe * JoeMiller
Сторінка з назвою `AdminGroup` може визначати групу для цього імені, і також може бути захищена ACL:
#acl AdminGroup:admin,read,write All:read * ПевнийКористувач * ІншийКористувач * Цей пункт наразі ігнорується. Будь-який інший текст не у списку першого рівня ігнорується.
Пункти списку першого рівня містять один та лише один пробіл перед зірочкою (а також один пробіл після зірочки). Наступні приклади не будуть працювати:
* певний користувач -- два пробіли, тож це не список першого рівня
Можна налаштувати які назви сторінок вважатимуться сторінками визначення груп (наприклад, для вікі не англійською мовою):
page_group_regex = u'[a-z]Group$' # це - початкове значення
Якщо зміни на сторінці групи не діють, вкажіть МоінМоін перебудувати кеш шляхом видалення усіх файлів у каталозі path_to_your_wiki_instance/data/cache/wikidicts/
10. Приклади використання
10.1. Публічний Вікі у Інтернет
При такому використані важливо використовувати ACL лише за необхідності. Вікі залежать від відкритості інформації та свободи редагування. Безпека досягається шляхом вичищання некоректного змісту. Тож в цілому потреби у ACL немає. Надмірне використання ACL може зруйнувати спосіб роботи вікі.
Тому ACL слід або зовсім не використовувати (початкова конфігурація), або надати wikiconfig.py приблизно такий вигляд:
acl_rights_before = u'ВікіРедактор:read,write,admin,delete,revert +AdminGroup:admin BadGuy:'
Вам підійде таке початкове значення параметра acl_rights_default:
acl_rights_default = u'Known:read,write,delete,revert All:read,write'
Радимо вам мати невелику групу довірених адміністраторів у `AdminGroup` (вони мають добре знати принципи роботи вікі, у іншому разі вони можуть випадково зіпсувати принципи роботи вікі: бути відкритим, не бути закритим та замкненим!).
При використанні `AdminGroup`, слід зробити сторінку з назвою `AdminGroup` та використовувати її для визначення осіб, які мають повноваження адміністраторів.
Наведене вище правило для `BadGuy` блокує йому доступ, він не зможе нічого читати або редагувати з цього облікового запису. Це має сенс лише як тимчасове явище, у іншому разі простіше видалити цей обліковий рахунок. Звичайно, `BadGuy` може діяти анонімно, тож це не є реальним захистом (тут має спрацьовувати м'яка безпека).
10.2. Вікі у якості простої CMS
Якщо вам потрібна вікі для простого створення веб-сайту, але вам не потрібне публічне редагування (за винятком кількох веб-майстрів), використовуйте такий wikiconfig.py:
acl_rights_default = u'All:read' acl_rights_before = u'ВебМайстер,ІншийВебМайстер:read,write,admin,delete,revert'
Тож кожен зможе переглядати ваш сайт, але лише веб-майстри зможуть робити все інше. Для сторінок, робота над якими ще не закінчена можна встановити
#acl All:
щоб ніхто інший не мав змоги бачити незавершену сторінку. Коли робота над сторінкою завершена, не забудьте видалити цей рядок, щоб задіяти правила з `acl_rights_default`.
Деякі сторінки можуть припускати публічні коментарі (наприклад, сторінка з назвою `PublicComments`), тож для неї слід надати більше прав:
#acl All:read,write
10.3. Вікі у інтранет
Якщо ви хочете використовувати вікі у інтранет та довіряєте вашим користувачам (вони не робитимуть таких ворожих дій як блокування інших користувачів чи псування сторінок) адміністративні функції, ви можете використовувати:
acl_rights_default = u'Known:admin,read,write,delete,revert All:read,write' acl_rights_before = u'АдміністраторВікі,ВеликийНачальник:read,write,admin,delete,revert'
Тож кожен зможе читати, змінювати сторінки та ACL записи, `АдміністраторВікі` та `ВеликийНачальник` мають змогу робити будь-що, відомі користувачі отримують адміністративні права у acl_rights_default (вони їх отримують, якщо на сторінці не вказано інші ACL).
Підсумок:
- до нових сторінок автор сторінки може додати будь-які ACL, які забажає
- до існуючих сторінок, які ще не містять ACL, будь-який відомий користувач може встановити будь-які ACL, які забажає
будь-кого (за винятком `АдміністраторВікі` та `ВеликийНачальник`) може заблокувати будь-хто інший (але з "known") на сторінках без ACL
10.4. Вікі у якості публічної сторінки компанії
Якщо ви хочете використовувати вікі для сайту компанії, та не бажаєте, щоб кожен користувач міг змінювати сторінку компанії, можете вкзати подібні правила:
acl_rights_default = u"TrustedGroup:admin,read,write,delete,revert All:read" acl_rights_before = u"AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin"
Це означає:
- відомим та анонімним користувачам початково дозволено лише читати сторінки
для нових сторінках, користувачі з `TrustedGroup` можуть встановлювати будь-які ACL, які забажають
для існуючих сторінок, для яких не встановлено ACL, будь-який користувач з `TrustedGroup` може встановлювати будь-які ACL, які забажає
будь-який користувач, за винятком осіб з `AdminGroup`, може бути заблокований іншими адміністраторами або довіреними користувачами
особи з `TrustedGroup` отримують адміністративні повноваження на будь-яку сторінку, яку вони можуть змінювати, навіть якщо на ній вказані якісь ACL
10.5. Коментарі до сторінки доступної лише для читання
Ви можете додавати розділ коментарів для сторінки лише для читання використовуючи підсторінку з можливістю редагування, наступні користувачі будуть мати можливість запису. Наприклад, можна визначити сторінку `ПевнаСторінка` подібним чином:
#acl ПевнийКористувач:read,write All:read '''Зміст доступний лише для читання''' ... ''' Коментарі користувачів ''' <<Include(ПевнаСторінка/Коментарі)>>
Та визначення для сторінки `ПевнаСторінка/Коментарі`:
#acl All:read,write Додавайте коментарі до сторінки ПевнаСторінка.
11. Також дивіться
ДовідкаАвтоАдміністрування: Властивість Авто``Адміністрування дозволяє надавати користувачам адміністративні повноваження для піднабору вікі