Списки доступа

Списки доступа (access control lists, ACL) позволяют контролировать права пользователей или групп (которые можно произвольно задавать, см. ПомощьПоГруппам). Можно определить права доступа как для всей вики, так и для отдельных страниц.

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

Для использования списков доступа необходимо или иметь доступ к wikiconfig.py (для установки глобальных настроек), или иметь привилегию admin («администрирование») на странице, где необходимо задать (или изменить) списки доступа.

1. Права доступа и группы

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

При задании списков доступа можно указывать следующие привилегии:

• read (чтение) — пользователи имеют возможность читать страницу и просматривать прикреплённые файлы.

• write (запись) — пользователи имеют возможность изменять страницу и загружать прикреплённые файлы.

• delete (удаление) — пользователи имеют возможность удалять страницу и прикреплённые к ней файлы.

• revert (откат к более ранней версии) — пользователи имеют возможность восстанавливать более раннюю версию страницы.

• admin (администрирование) — пользователи имеют возможность изменять списки доступа путём правки директивы «#acl», в том числе, давать и отзывать привилегию «admin» для других пользователей.

Не существует отдельной привилегии для переименования страниц. Для переименования страницы пользователю необходимо иметь привилегии read, write и delete.

Анонимные (не представившиеся системе) пользователи не могут ни удалять, ни переименовывать страницы (даже если соответствующая привилегия указана для группы All).

Прикреплённые файлы наследуют списки доступа страницы, к которой они прикреплены.

Для добавления или изменения списков доступа на странице необходимо иметь на ней привилегию admin. Если Вы — администратор вики, то Вы можете установить для себя привилегию admin для всей вики (см. раздел по конфигурированию на уровне сайта ниже).

Допустимые привилегии указаны в параметре acl_rights_valid конфигурационного файла wikiconfig.py. Например, в нём можно указать все привилегии кроме delete для предотвращения удаления страниц (см. раздел по конфигурированию на уровне сайта ниже).

1.2. Группы

Права доступа могут указываться для отдельных учётных записей, групп (задаваемых в виде страниц на вики с перечислением входящих в них участников) или специальных групп (системных групп, имеющих предопределённый смысл). Далее используются следующие обозначения:

• ИмяПользователя — указанный субъект совпадает с именем учётной записи, действует только в случае полного совпадения (в том числе регистра).

• НекаяГруппа — имя группы, определённой пользователем (подробнее см. ПомощьПоГруппам).

• Trusted (доверяемые) — специальная группа, содержащая пользователей, аутентифицировавшихся доверяемым способом аутентификации.

• Known (известные) — специальная группа, содержащая всех аутентифицировавшихся пользователей.

• All (все) — специальная группа, означающая «кто угодно» (то есть, как представившихся системе, так и анонимных пользователей).

2. Синтаксис и примеры использования

Управление списками доступа в МойнМойн выполняется путём редактирования строки директивы на необходимой странице. Списки доступа должны быть на первой строке страницы (не считая комментариев) и иметь следующий синтаксис:

#acl [+-]ИмяПользователя[,НекаяГруппа,...]:[привилегия[,привилегия,...]] [[+-]ДругойПользователь:...] [[+-]Trusted:...] [[+-]Known:...] [[+-]All:...] [Default]

, где «ИмяПользователя», «НекаяГруппа», «привилегия» (возможность читать, писать, удалять, откатывать, администрировать) определены выше.

«Default» — специальная запись, которая вставляет в необходимом значение параметра acl_rights_default. Это описано подробнее в разделе «списки доступа по умолчанию» далее.

Использование пробелов между именем и привилегиями недопустимо. Например, «All: write,read» не является корректной строкой, задающей списки доступа.

Простой пример:

#acl АлександрПривалов:read,write,delete,revert,admin ГруппаРедакторы:read,write,revert All:read

В данном примере пользователю АлександрПривалов разрешены запись и чтение, наряду с другими действиями, любому же, включённому в группу ГруппаРедакторы доступны чтение, запись и откат данной страницы. Все прочие пользователи имеют возможность только читать её (учтите, что настройки прав доступа сайта, указанные в wikiconfig.py, имеют более высокий приоритет по сравнению с правами доступа, указанными на странице). См. также «примеры использования» ниже.

3. Конфигурация в масштабе всего сайта

Представленные далее параметры конфигурации используются для настройки списков доступа в рамках всей вики, и устанавливаются они в файле wikiconfig.py (также см. КакНастраивать).

Теперь рассмотрим семантику каждого из параметров.

• Списки доступа, указанные в параметре acl_rights_before, имеют наивысший приоритет (ввиду того, что алгоритм применения списков доступа применяет первую подходящую запись и того, что данные списки доступа просматриваются в первую очередь). Данный параметр обычно используется для настройки параметров доступа администраторов и редакторов.

• Списки доступа, указанные в параметре acl_rights_default используются в случае, если никаких отдельных списков доступа для страницы не задано. Это равноценно указанию списков доступа, заданных в этом параметре, на странице. Эти же правила добавляются в месте использования параметра Default в списках доступа страницы.

• Списки доступа, указанные в параметре acl_rights_after используются для низкоприоритетных настроек, которые не хотелось бы забывать (например, предоставление доступа на чтение любому пользователю).

Фактически, данные правила применяются до, вместо (или во время) и после обработки списков доступа страницы.

Префикс «u» перед строковыми литералами означает, что это Unicode-строки, и является обязательным.

4. Обработка списков доступа

Данный раздел описывает процесс применения списков доступа странице, содержащей их. Аналогично применяются для всей вики списки доступа, указанные в конфигурации (см. КакНастраивать).

4.1. Процесс обработки элементов

Когда пользователь пытается получить доступ к странице с установленными списками доступа, записи в списке обрабатываются в порядке их нахождения. Первая запись, которой удовлетворяет пользователь, определяет, может ли пользователь получить доступ или нет, и обработка на этом завершается. В соответствии с этим алгоритмом, рекомендуется упорядочивать записи в списках доступа в следующем порядке:

1. Отдельные имена учётных записей
2. Группы (от частных к более общим)

3. Trusted

4. Known

5. All

Например, ниже рассмотрен случай, когда пользователь КакойТоПользователь получает привилегии на чтение и запись ресурсов, у которых установлены приведённые списки доступа, члены группы КакаяТоГруппа получают возможность также администрировать данные ресурсы, все же остальные могут только их читать. Важно отметить, что в случае принадлежности пользователя КакойТоПользователь группе КакаяТоГруппа он не получит привилегию администрирования.

#acl КакойТоПользователь:read,write КакаяТоГруппа:read,write,admin All:read

4.2. Префиксы-модификаторы

В целях увеличения гибкости также имеются модификаторы параметров доступа: префиксы «+» и «-». В случае их использования обработка элементов останавливается только в том случае, когда в данном элементе указана соответствующая привилегия (помимо соответствия пользователя). В противном случае, обработка списка продолжается. При использовании в подошедшем элементе модификатора «+» доступ предоставляется, при использовании модификатора «-» — запрещается.

Например, в предположении принадлежности пользователя КакойТоПользователь группе КакаяТоГруппа предыдущий пример можно переписать следующим образом:

#acl -КакойТоПользователь:admin КакаяТоГруппа:read,write,admin All:read

В случае запроса привилегии на администрирование пользователем КакойТоПользователь, ему будет отказано и обработка списков доступа остановится. Во всех других случаях (другой пользователь или другая привилегия), обработка продолжится.

#acl +All:read -КакойТоПользователь:admin КакаяТоГруппа:read,write,admin

+All:read позволяет любому пользователю получить доступ на чтение, после чего обработка списков доступа остановится. Во всех прочих случаях (при запросе иных привилегий) обработка продолжится. Если будет запрошена административная привилегия для пользователя КакойТоПользователь, в ней будет отказано и обработка прекратится. Во всех прочих случаях обработка продолжится. В конце концов, если пользователь, состоящий в группе КакаяТоГруппа, запрашивает привилегию ,то он получит её, если она есть среди read,write,admin, и в ней будет отказано в противном случае. Все другие пользователи иных привилегий не имеют (если только они не указаны в конфигурации сайта).

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

5. Использование «Default»

Иногда бывает необходимо незначительно изменить списки доступа по сравнению с их значениями по умолчанию. Например, предположим, что имеется следующая конфигурация:

   1 acl_rights_default = u"TrustedGroup:read,write,delete,revert All:read"
   2 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

Рассмотрим следующий пример:

   1 acl_rights_before  = u"AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin"

Списки доступа обрабатываются в порядке «acl_rights_before — списки доступа страницы/acl_rights_default — acl_rights_after», слева направо.

Поэтому, обработка начинается с «acl_rights_before», с записи AdminGroup:... — она будет выполнена, если субъект, запрашивающий привилегию, состоит в данной группе. Если это так, то пользователь получает привилегии на администрирование, чтение, запись, удаление ,откат и обработка списков доступа завершается.

Если же условие записи не выполнилось, обрабатывается запись +TrustedGroup:admin — она выполнится, если пользователь является членом группы TrustedGroup. В этом случае будет дана привилегия администрирования и обработка будет продолжена в случае, если запрашивалась иная привилегия. Поэтому, если пользователь является членом других групп, то он получит привилегии, предоставленные им, наряду с привилегиями, предоставленными в записях Known: и All:.

Если же условие не выполнится, то начнется обработка списков доступа страницы (при их наличии) или списков доступа по умолчанию (в противном случае) и, в самом конце, обработаются списки доступа "after".

Несмотря на то, что наследование настроек по умолчанию приводит к тому же эффекту, у него есть преимущество в виде автоматического использования новых настроек по умолчанию при их изменении.

6. Иерархическая обработка списков доступа

В случае включения параметра acl_hierarchic (см. выше), пространство страниц (а не только их имён) рассматривается в виде дерева и права доступа к страницам верхнего уровня влияют на права доступа к вложенным страницам.

Если обрабатываемая страница не содержит инструкции #acl, то используются списки доступа родительской страницы (или её родительской страницы, и так далее до верхнего уровня иерархии включительно).

Рассмотрим порядок обработки списков доступа для страницы А/Б/В/Г в зависимости от использования данного параметра:

Списки доступа по умолчанию обрабатываются как и раньше, но используются только в случае отсутствия спецификации списков доступа у всех страниц в иерархии (а не только у текущей страницы)

Примечание. Поведение иерархической обработки списков доступа отличалось в версиях МойнМойн до 1.8.4: списки доступа родительских страниц больше не добавляются к спискам доступа вложенных страниц. Все привилегии для вложенной страницы должны быть указаны в ней.

7. Примеры использования

7.1. Публичная вики сообщества в интернете

В данном случае важно использовать списки доступа только в тех случаях, когда они действительно нужны. Вики базируются на открытости информации и свободе редактирования и используют мягкие способы защиты от нежелательного содержимого, поэтому большой необходимости в списках доступа нет, и чрезмерное их использование может нарушить механизм работы вики.

В случае же использования списков доступа, предлагается следующая конфигурация wikiconfig.py:

   1 acl_rights_before = u'РедакторВики:read,write,admin,delete,revert +AdminGroup:admin ВанДал:'

Значение параметра acl_rights_default подходит для большинства случаев:

   1 acl_rights_default = u'Known:read,write,delete,revert All:read,write'

Рекомендуется включать в группу AdminGroup небольшое число доверенных администраторов (они должны понимать, как работают вики).

Для использования группы AdminGroup необходимо создать одноимённую страницу и указать там участников, в ней состоящих (подробнее см. ПомощьПоГруппам).

Указание прав доступа аналогично приведённым в примере для ВанДал блокирует пользователя — он не может ничего делать (в том числе, читать и редактировать), используя свою учётную запись. Это имеет смысл в случае временной блокировки ,в противном случае можно просто удалить учётную запись (или отключить её посредством SystemAdmin --- ссылка на страницу помощи). Конечно, пользователь может работать не используя учётную запись, поэтому это не является действенным способом защиты (это тот случай, когда применяются мягкие средства защиты).

7.2. Вики как система управления содержимым (CMS)

В случае использования вики как простого способа создания содержимого сайта, недоступного для публичного редактирования, можно использовать следующие настройки в wikiconfig.py:

   1 acl_rights_default = u''
   2 acl_rights_after = u'All:read'
   3 acl_rights_before  = u'WebMaster,OtherWebMaster:read,write,admin,delete,revert'

В этом случае кто угодно может получить доступ на чтение, но только управляющие работой сайта могут делать что-то иное. Во время работы над новой страницей они могут поместить

#acl All:

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

Некоторые страницы могут допускать публичное редактирование (например, страница ГостеваяКнига), в таком случае для неё можно указать дополнительные права:

#acl All:read,write

7.3. Внутрикорпоративная вики

При использовании вики внутри корпоративной сети в случае возможности доверения пользователям административных привилегий (они не творят безобразия вроде блокирования друг друга или вандализма страниц), можно использовать следующую конфигурацию:

   1 acl_rights_default = u'Known:admin,read,write,delete,revert All:read,write'
   2 acl_rights_before  = u'АдминистраторВики,ГенеральныйДиректор:read,write,admin,delete,revert'

Таким образом, любой авторизованный пользователь получает все привилегии: АдминистраторВики и ГенеральныйДиректор имеют возможность делать что угодно в любом случае, аналогичные привилегии даются зарегистрированным пользователям списком acl_rights_default (они будут их иметь, пока не настроены списки доступа страницы)

В результате:

• При создании страницы автор может установить произвольные списки доступа.
• Для существующих страниц могут быть установлены произвольные списки доступа, если они ещё не заданы.

• Кто угодно (кроме пользователей АдминистраторВики и ГенеральныйДиректор) может быть заблокирован кем угодно на страницах с ещё не заданными списками доступа.

7.4. Вики как публичное представительство компании

В случае использования вики как сайта компании, как правило, отсутствует желание давать возможность её править кому угодно. В таком случае, можно использовать что-то вроде этого:

   1 acl_rights_default = u"TrustedGroup:admin,read,write,delete,revert All:read"
   2 acl_rights_before  = u"AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin"

Это означает, что:

• По умолчанию зарегистрированные и анонимные пользователи имеют возможность только просматривать страницы

• При создании новой страницы (или на страницах с ещё не заданными списками доступа) пользователи, состоящие в группе TrustedGroup, могут установить произвольные списки доступа

• Кто угодно, кроме пользователей, состоящих в группе AdminGroup, может быть заблокирован другими администраторами или доверяемыми пользователями

• Доверяемые пользователи имеют административные права на любой странице, где они имеют право на запись, даже если для неё заданы списки доступа.

7.5. Комментарии для страницы только для чтения

Можно добавить раздел комментариев в страницу только для чтения путём использования вложенной страницы, доступной на запись. Например, можно задать списки доступа для страницы SomePage следующим образом:

#acl SomeUser:read,write All:read
'''Некое содержимое только для чтения'''

...

''' Комментарии '''
<<Include(SomePage/Комментарии)>>

И задать SomePage/Комментарии следующим образом:

#acl All:read,write
Комментарии для страницы SomePage можно оставить здесь.

См. также КакНастраивать/ВспомогательнаяСтраница.

8. См. также

• ПомощьПоAutoAdmin: данная возможность позволяет предоставлять административные права для подмножеств страниц вики.