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

Наявні права ACL: read - хто може переглядати сторінку write - хто може редагувати сторінку delete - хто може видаляти сторінку revert - что може повертати сторінку до попередньої версії admin - хто може змінювати рядок "#acl" на сторінці. Використовувати ACL у моін дуже просто, треба додати керуючий рядок згори сторінки, наприклад такий: /!\ Ви вже повинні мати право admin, щоб мати змогу додавати чи змінювати цей рядок acl - перегляньте сторінки ДовідкаКонфігурування та ДовідкаАвтоАдміністрування. Цей рядок дозволяє користувачу ПевнийКористувач переглядати та редагувати цю сторінку, усі інші зможуть лише переглядати її, але не редагувати (якщо ви не встановили для цього спеціальні параметри у конфігурації сайту). При роботі системи моін вікі вкладення також захищаються ACL записом сторінки, до якої вони належать. /!\ Вкладення не захищаються, якщо на сервері налаштовано прямий доступ до вкладень (тобто, коли параметр використовується параметр attachments у файлі wikiconfig.py).

Для налаштовування ACL на сайті моін є наступні конфігураційні параметри. ПараметрТипове значенняОписacl_rights_beforeu""застосовується перед сторінкою чи типовими ACLacl_rights_afteru""застосовується після сторінки чи типових ACLacl_rights_defaultu"Trusted:read,write,delete,revert \Known:read,write,delete,revert \All:read,write"застосовується лише коли не вказано інших 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$'

Кожен рядок має такий синтаксис: Де: Користувач - ім'я користувача, права застосовуються лише для користувача з таким іменем. Група - назва сторінки, що відповідає 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.

Є певні права, які можна використовувати у записах ACL. Зверніть увагу, що DeletePage та RenamePage неприпустимі, якщо користувач не належить до Known, навіть якщо надано право delete. readВказані користувачі матимуть змогу переглядати текст цієї сторінки. writeВказані користувачі матимуть змогу редагувати цю сторінку. deleteВказані користувачі матимуть змогу видаляти цю сторінку та її вкладення. revertВказані користувачі матимуть змогу повертати цю сторінку до попередньої версії. adminВказані користувачі матимуть адміністративні права на цю сторінку. Тобто вони зможуть змінювати її ACL, включно з надаванням та забиранням права "admin" у інших користувачів. /!\ Немає окремого права rename: для перейменування потрібно щоб користувач мав права read, write та delete.

Коли користувач намагається отримати доступ до певного, захищеного ACL ресурсу, то ACL обробляються у порядку їх появи. Перший ACL, що відповідає користувачу визначає чи матиме користувач доступ до цього ресурсу, обробка припиняється одразу при виявленні відповідності імені користувача у записі ACL. (!) Оскільки використовується алгоритм першої відповідності, вам слід сортувати ваші ACL: спочатку окремі імена користувачів, потім спеціальні групи, потім загальні групи, потім Known та зрештою All. Наприклад, наступний ACL вказує, що ПевнийКористувач може переглядати та редагувати ресурси, що захищені цим ACL, а будь-який член групи ПевнаГрупа (окрім ПевнийКористувач, якщо він входить до цієї групи) має адміністративні права, а всі інші можуть лише переглядати ресурс. Щоб зробити систему більш гнучкою, є два модифікатори: префікси '+' та '-'. При їх використанні обробка припиняється лише якщо певне право для певного користувача відповідає користувачу та праву у вказаному ACL, але продовжується, якщо ви шукаєте інше право (або іншого користувача). У випадку '+' право буде надане, у випадку '-' право буде заборонено (при зупинці обробки). Наприклад, вважаємо що ПевнийКористувач є членом ПевнаГрупа, наведений вище ACL можна переписати так: Цей приклад є специфічним для ПевнийКористувач,оскільки коли для користувача ПевнийКористувач запитується право admin, доступ буде заборонено та обробка припиняється. У іншому випадку, обробка продовжується. Або навіть: +All:read означає що коли будь-який користувач запитує право read, він отримає доступ та обробка зупиняється. У іншому випадку обробка продовжується. Якщо право admin запитується для користувача ПевнийКористувач, доступ буде заборонено та обробка зупиняється. У іншому випадку обробка продовжується. Зрештою, якщо член групи ПевнаГрупа запитує деяке право, доступ надається, доступ надається якщо це право вказане, або не надається у іншому випадку. Усі інші користувачі не мають інших прав, окрім визначених у конфігурації. Зверніть увагу, можливо, ви не захочете використовувати другий та третій приклади у записах ACL на сторінках. Хоча, вони дуже корисні у записах конфігурації сайтів.

Іноді може знадобитися надати комусь права без суттєвого впливу на типові права. Наприклад, уявімо, що у вашій конфігурації є наступні записи: Тепер, є сторінка, до якої ви хочете надати доступ "write" для користувача ПевнийКористувач, але також бажаєте зберегти типову поведінку для All та TrustedGroup. Це можна легко зробити користуючись записом Default: Це призведе до додавання записів з acl_rights_default замість слова Default. Іншими словами, наведений вище запис еквівалентний наступному: Погляньте на перший приклад у цьому розділі: 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.

{i} Нова властивість у версії 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, знайдених на сторінках ієрархії.

Групи користувачів спрощують вказування прав для великих груп. Зазвичай, назва сторінки групи закінчується на Group наприклад ДрузіGroup. Це дозволяє MoinMoin трактувати їх як список користувачів. Типовий шаблон можна змінити (наприклад для інших мов, тощо.), дивіться ДовідкаКонфігурування. Лише друзі користувача ПевнийКористувач можуть читати та редагувати сторінку: ПевнийКористувач/ДрузіGroup буде сторінкою зі списком верхнього рівня, в якому перелічені імена користувачів вікі у цій групі: Сторінка з назвою AdminGroup може визначати групу для цього імені, і також може бути захищена ACL: /!\ Пункти списку першого рівня містять один та лише один пробіл перед зірочкою (а також один пробіл після зірочки). Наступні приклади не будуть працювати: Можна налаштувати які назви сторінок вважатимуться сторінками визначення груп (наприклад, для вікі не англійською мовою): /!\ Якщо зміни на сторінці групи не діють, вкажіть МоінМоін перебудувати кеш шляхом видалення усіх файлів у каталозі path_to_your_wiki_instance/data/cache/wikidicts/

При такому використані важливо використовувати ACL лише за необхідності. Вікі залежать від відкритості інформації та свободи редагування. Безпека досягається шляхом вичищання некоректного змісту. Тож в цілому потреби у ACL немає. Надмірне використання ACL може зруйнувати спосіб роботи вікі. Тому ACL слід або зовсім не використовувати (початкова конфігурація), або надати wikiconfig.py приблизно такий вигляд: Вам підійде таке початкове значення параметра acl_rights_default: Радимо вам мати невелику групу довірених адміністраторів у AdminGroup (вони мають добре знати принципи роботи вікі, у іншому разі вони можуть випадково зіпсувати принципи роботи вікі: бути відкритим, не бути закритим та замкненим!). При використанні AdminGroup, слід зробити сторінку з назвою AdminGroup та використовувати її для визначення осіб, які мають повноваження адміністраторів. Наведене вище правило для BadGuy блокує йому доступ, він не зможе нічого читати або редагувати з цього облікового запису. Це має сенс лише як тимчасове явище, у іншому разі простіше видалити цей обліковий рахунок. Звичайно, BadGuy може діяти анонімно, тож це не є реальним захистом (тут має спрацьовувати м'яка безпека).

Якщо вам потрібна вікі для простого створення веб-сайту, але вам не потрібне публічне редагування (за винятком кількох веб-майстрів), використовуйте такий wikiconfig.py: Тож кожен зможе переглядати ваш сайт, але лише веб-майстри зможуть робити все інше. Для сторінок, робота над якими ще не закінчена можна встановити щоб ніхто інший не мав змоги бачити незавершену сторінку. Коли робота над сторінкою завершена, не забудьте видалити цей рядок, щоб задіяти правила з acl_rights_default. Деякі сторінки можуть припускати публічні коментарі (наприклад, сторінка з назвою PublicComments), тож для неї слід надати більше прав:

Якщо ви хочете використовувати вікі у інтранет та довіряєте вашим користувачам (вони не робитимуть таких ворожих дій як блокування інших користувачів чи псування сторінок) адміністративні функції, ви можете використовувати: Тож кожен зможе читати, змінювати сторінки та ACL записи, АдміністраторВікі та ВеликийНачальник мають змогу робити будь-що, відомі користувачі отримують адміністративні права у acl_rights_default (вони їх отримують, якщо на сторінці не вказано інші ACL). Підсумок: до нових сторінок автор сторінки може додати будь-які ACL, які забажає до існуючих сторінок, які ще не містять ACL, будь-який відомий користувач може встановити будь-які ACL, які забажає будь-кого (за винятком АдміністраторВікі та ВеликийНачальник) може заблокувати будь-хто інший (але з "known") на сторінках без ACL

Якщо ви хочете використовувати вікі для сайту компанії, та не бажаєте, щоб кожен користувач міг змінювати сторінку компанії, можете вкзати подібні правила: Це означає: відомим та анонімним користувачам початково дозволено лише читати сторінки для нових сторінках, користувачі з TrustedGroup можуть встановлювати будь-які ACL, які забажають для існуючих сторінок, для яких не встановлено ACL, будь-який користувач з TrustedGroup може встановлювати будь-які ACL, які забажає будь-який користувач, за винятком осіб з AdminGroup, може бути заблокований іншими адміністраторами або довіреними користувачами особи з TrustedGroup отримують адміністративні повноваження на будь-яку сторінку, яку вони можуть змінювати, навіть якщо на ній вказані якісь ACL

Ви можете додавати розділ коментарів для сторінки лише для читання використовуючи підсторінку з можливістю редагування, наступні користувачі будуть мати можливість запису. Наприклад, можна визначити сторінку ПевнаСторінка подібним чином: >]]>Та визначення для сторінки ПевнаСторінка/Коментарі:

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