IntraACL/ru

What links here (1) →

IntraACL — лучшее расширение для MediaWiki, связанное с поддержкой прав доступа к страницам 8-). Требует патча в код MediaWiki. Создано на основе отлаженного и очень сильно допиленного HaloACL.

• Домашняя страница: http://wiki.4intra.net/IntraACL
• Лицензия: GPLv3
• Copyright (c) 2010+, Vitaliy Filippov, Stas Fomin
• Copyright 2009, ontoprise GmbH
• Обзор кода

Введение

Права в MediaWiki — общая ситуация

MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content. But with the massive increase of MediaWiki use in corporate intranets and the many CMS-like features emerging, demand for tighter security is emerging.

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

Поэтому архитектура MediaWiki не рассчитана на защиту чего-то от кого-то, кроме правки от анонимусов. Существует множество механизмов, с помощью которых защиту от просмотра можно обойти (включения страниц, свежие правки и т. п.), особенно с учётом возможной установки любого из 1700+ расширений, каждое из которых может осуществлять прямой доступ к БД (и хорошо, что может, а то ворочалась бы вики, как прочий неторопливый «ынтырпрайз»).

Примеры подобных механизмов описаны здесь: Security issues with authorization extensions, плюс есть страница со сравнением существующих механизмов защиты, с которой мы и узнали про HaloACL.

HaloACL и в оригинале уже решает практически все эти проблемы. Однако, когда мы попробовали его поиспользовать, оказалось, что у него свои недостатки — огромное число багов и неторопливая работа интерфейсов (спасибо YAHOO UI). Пришлось сначала дорабатывать, а когда доработки зашли слишком далеко — давать собственное название и форкать.

Фичи IntraACL

• Интерактивный редактор прав доступа (спецстраница).
• Возможность создания страниц вместе с защитой.
• Защита страниц.
• Защита категорий.
• Защита пространств имён.
• Защита семантических свойств — не протестирована и почти наверняка разломана в процессе доработки.
• Возможность включения прав друг в друга.
• Определения прав доступа на вики-страницах в специальном пространстве имён.
• Группы пользователей, возможность включения групп в группы. Не стандартный MediaWiki-механизм групп (sysop, bureaucrat и т. п.), а собственный механизм, хранятся также на вики-страницах.
• Возможность лёгкой защиты включаемого в статью содержимого.

Защита механизмов доступа

На странице Security issues with authorization extensions описаны следующие механизмы, которые для тех или иных реализаций прав доступа могут представлять собой «дыру». Относительно IntraACL их статус следующий:

• ✓ Включение страниц — если страница недоступна для чтения, всё выглядит так, как будто её нет. Текст при этом можно заменить на пустой.
• ✓ Предзагрузка текста при правке с другой страницы — текст заменяется на «доступ запрещён».
• ✓ Экспорт/импорт — недоступные статьи не экспортируются и не могут быть перезаписаны импортом.
• ✓ Ленты свежих правок — недоступные статьи не отображаются в лентах.
• ✓ Списки, поиск — аналогично, в списках недоступных статей нет.
• ✓ Diff’ы, история
• ✓ api.php?action=query
• ✓ Сырой/печатный вид
• ✓ Связанные права
• ✓ Доступ не даётся создателю неявно
• ✓ Кэширование
• ✓ Перенаправления
• ✓ Правка секций
• ✓ Другие расширения — если совместимы с IntraACL/HaloACL. Все расширения из состава Mediawiki4Intranet — совместимы.
• ✓ Слежение за страницами — если пользователь раньше следил за страницей, а потом она была закрыта, сообщения о её изменениях ему больше не придут.
• ✓ Перемещение страниц — если переместить защищённую страницу, права будут перемещены вместе с ней, а старая страница получит права, равные включению прав новой, для защиты «свежих правок» (!).

• ✕ Прямой доступ к содержимому загруженных файлов — пока что не защищается, так как требует интеграции прав с веб-сервером.

Сравнение с HaloACL

Немного статистики: Diffstat diff’а -NaurpBb между оригиналом HaloACL и IntraACL:

• Без учёта YUI, пакованных скриптов, картинок — удалено файлов: 36, строк: 15387.
• YUI + пакованные скрипты — удалено файлов: 33, строк: 33606.
• Картинки — удалено файлов: 39, добавлено: 1.
• Изменено файлов: 28, строк: +5126/-11568.
• Добавлено файлов: 24, строк: 5483.

Предыдущие данные, видимо, были некорректны, была попытка сосчитать статистику по сумме всех изменений из svn. Эти тоже надо ещё проверить :)

Общие черты

Все определения прав, групп и т. п. хранятся как вики-страницы в специальном пространстве имён ACL.

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

Полностью совместим интерфейс для расширений (по сути, состоящий из одного метод Title::userCanReadEx()).

Большинство идентификаторов и соглашений по именованию в коде оставлены неизменными — мы не хотим побыстрее забыть свои корни (как в Эстонии — «у наас теперь самый умный тот, кто побыстрее русский язык забудет»).

Также и терминология в основе прав HaloACL и IntraACL лежит общая:

SD (Security Descriptor)

Права для чего-нибудь. Чем-нибудь может быть страница, категория, пространство имён. В Semantic MediaWiki чем-нибудь также может быть свойство (property). SD может включать в себя IR (Inline Rights), включение других SD или PR (Predefined Rights), и права на изменение самого SD.

PR (Predefined right или Right template)

Шаблон прав, ничего конкретно не защищающий. По структуре совпадает с SD. Его можно включать в другие шаблоны или в SD, и тогда права, определённые в нём, распространяются на то, куда он включён.

IR (Inline right)

«Базовая единица» прав — «одно право». Имеет две характеристики:

• кому выдано — это набор пользователей и/или набору групп (не вики-групп, а HaloACL-групп).
• что выдано — набор прав.

Доступны следующие права: чтение, запись, удаление, переименование, создание новых статей, (только в IntraACL) изменение прав статьи. В оригинальном HaloACL также выделяются права на: добавление семантических аннотаций, редактирование через форму, редактирование через WYSIWYG-редактор. В IntraACL эти 3 права приравнены к праву редактирования (ну что за бред — разрешать править статью через WYSIWYG, но не разрешать просто) и ликвидированы.

Отличия

Редактор

thumb|right|200px|Редактор прав HaloACL В HaloACL интерфейс служебной страницы реализован неудобно, глючит и тормозит, на основе JavaScript-фреймворка YAHOO UI (в жизни к нему теперь не притронусь). Кроме того, он переусложнён (можно написать раз в 5 меньше кода), и ужасен с точки зрения удобства пользователя — он пошаговый и не очень интерактивный.

thumb|right|200px|Редактор прав IntraACL В IntraACL интерфейс гораздо дружелюбнее и написан на «голом» JavaScript’е, без использования каких-либо фреймворков вообще (кроме МедиаВиковского AJAX’а — sajax_do_call), посему работает очень шустро и приятно. Аналогично реализован и редактор групп, и списка шаблонов быстрого доступа.

Пример

Пример создания прав в редакторе HaloACL:

1. Сначала нужно выбрать, что создаём — права, шаблон, или «личный шаблон».
2. Потом выбрать на что создаём права — на страницу, категорию, namespace, свойство. Опция «свойство» не скрывается, даже если Semantic MediaWiki не установлена.
3. Ввести имя и нажать «Далее». После этого поменять имя, естественно, уже нельзя.
4. Нажать «Create right». Откроется страшная форма с кучей полей.
5. Ввести имя и описание для «права». То есть словесное описание. Зачем оно — понятия не имею.
6. Выбрать права галочками.
7. Выбрать «кому» из 5 вариантов («мне», «набору юзеров/групп», «всем», «всем зарегистрированным», «всем анонимным»).
8. Выбрать галочками, кому же всё-таки, в случае набора. Выбор ведётся из YUI TreeView, фильтруемого тут же, и со страшной силой тормозит.
9. Чтобы просмотреть, кому что-то выдано сейчас, надо переключиться на другую вкладку.
10. После этого нажать «Сохранить право». Но если вы думаете, что квест закончен и всё сохранилось, очень ошибаетесь.
11. Нажать «Далее».
12. Ещё одной такой же формочкой задать права на изменение самих прав.
13. Нажать «Далее».
14. Нажать «Сохранить».

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

В IntraACL, с другой стороны, редактор интерактивный, не пошаговый и всегда показывает то, что будет сохранять.

• В любой момент можно поменять, что защищаем, добавить права, права на изменения прав или включения шаблонов.
• Везде работает автозаполнение (autocomplete) — подсказывает страницы, пространства имён, категории, пользователей, группы.
• При выборе пользователя или группы состояние флажков (✓) меняется так, чтобы отражать текущие права выбранного пользователя/группы.
• Причём, редактор подгружает включаемые определения групп и шаблонов и вычисляет реальные права, учитывая, если право было дано пользователю, потому что он находится в группе или если право дано через шаблон.
• Дать или отобрать права очень легко — нужно просто отметить или снять флажок. Текст определения прав при этом изменится.
• Кнопка «Сохранить» ровно одна :)

Панель

Переделана панель, появляющаяся при редактировании страниц:

• Не требует тяжёлого JavaScript’а.
• Сохраняет состояние при нажатии «Предпросмотра».
• Показывает ссылки на шаблоны быстрого доступа, чтобы можно было просмотреть их содержимое.
• Подсказывает, какие ещё права действуют на страницу (то есть права на пространства имён и категории).
• Подсказывает, когда вы не можете редактировать права страницы.
• Подсказывает, какие шаблоны и изображения использованы на странице и на каких страницах они ещё использованы, и даёт возможность легко распространить защиту на них.

Кросс-линковка

В оригинальном HaloACL есть проблема с лёгким доступом к определениям и обратно, так как практически нигде нет ссылок. В IntraACL наоборот, они практически везде есть — например, ссылки со страницы на соответствующий ей ACL, с ACL на соответствующую ему страницу и на интерактивный редактор, и так далее.

Право manage

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

Вместе с тем и делать, чтобы все права на изменение прав наследовались, тоже не очень правильно — нужно различать «управление правами страницы» и «управление шаблоном». То есть, хотелось бы иметь возможность выдать в шаблоне кому-нибудь права на управление страницей, но при этом не выдавать права на управление самим шаблоном.

В IntraACL это возможно — есть дополнительное право «manage» в составе обычной парсер-функции access, которое и является «правом на управление страницей», но не действует на шаблон. Пример использования:

{{#access: assigned to = User:Someone | actions = *, manage}}
{{#manage rights: assigned to = User:Another}}

В чём же различие между actions=manage и manage rights?

• Если этот текст — часть прав (SD) страницы, разницы нет. Пользователи Someone и Another получат права на изменение этого SD.
• Если этот текст — часть прав (SD) категории или пространства имён, actions=manage даст пользователю Someone право редактировать права (SD) страниц, находящихся в этой категории или пространстве имён, но не даст прав на изменение SD самой этой категории или пространства имён. В то же время, manage rights даст Another права редактировать SD категории/пространства имён, но никак не отразится на его правах редактирования SD страниц.
• Аналогично с шаблонами прав (PR). Если этот текст — часть шаблона прав (PR), actions=manage даст пользователю Someone право редактировать права (SD) страниц, в SD которых включён этот шаблон, но не даст ему редактировать шаблон. В то же время, manage rights даст Another права редактировать шаблон (PR), но никак не отразится на его правах редактирования SD страниц, в которые этот шаблон включён.

Упрощения

Убраны права на «добавление семантических аннотаций», «редактирование через форму», «редактирование через WYSIWYG-редактор», ибо приравнены просто к праву редактирования.

Убраны такие понятия, как «Личный шаблон по умолчанию» (Default user template), «Белый список» (Whitelist). Первое потому, что неудобно в одном месте задавать шаблон по умолчанию, а в другом — список шаблонов, доступных для быстрого выбора на панельке. Удобно в общем списке выбирать тот, который будет по умолчанию. Второе потому, что «белый список» только усложняет проверки — на страницы можно просто раздать права на чтение, что будет эквивалентно.

Убрана возможность перевода названий функций парсера и их параметров, ибо нефиг разводить 1С («Если (хаха) то (хаха) КонецЕсли»). Названия всегда на английском.

Разрешено включать не только шаблоны прав (PR), но и дескрипторы (SD).

Рефакторинг кода

Огромный объём рефакторинга. Например, константы перемещены из отдельных классов в общий, локализация упрощена, функции парсера более не полагаются на то, что при сохранении статья будет parse’иться, а также позволяют массовое редактирование и импорт/экспорт (то есть редактирование нескольких страниц за запрос). Разрешается изменение некорректных определений, дабы если что, пользователям не приходилось тут же бежать к админам.