Difference between revisions of "IntraACL/ru"
(→Защита механизмов доступа) |
(→Защита механизмов доступа) |
||
Line 32: | Line 32: | ||
<div style="color: #0a0"> | <div style="color: #0a0"> | ||
− | * ✓ Включение | + | * ✓ Включение страниц — если страница недоступна для чтения, всё выглядит так, как будто её нет. Текст при этом можно заменить на пустой. |
− | * ✓ Предзагрузка текста при правке с другой | + | * ✓ Предзагрузка текста при правке с другой страницы — текст заменяется на «доступ запрещён». |
− | * ✓ Экспорт/ | + | * ✓ Экспорт/импорт — недоступные статьи не экспортируются и не могут быть перезаписаны импортом. |
− | * ✓ Ленты свежих | + | * ✓ Ленты свежих правок — недоступные статьи не отображаются в лентах. |
− | * ✓ Списки, | + | * ✓ Списки, поиск — аналогично, в списках недоступных статей нет. |
* ✓ Diff’ы, история | * ✓ Diff’ы, история | ||
* ✓ api.php?action=query | * ✓ api.php?action=query |
Revision as of 12:37, 24 February 2011
IntraACL — лучшее расширение для MediaWiki, связанное с поддержкой прав доступа к страницам 8-). Требует патча в код MediaWiki. Создано на основе отлаженного и очень сильно допиленного HaloACL.
Contents
[hide]Права в 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). Пришлось сначала дорабатывать, а когда доработки зашли слишком далеко — давать собственное название и форкать.
Фичи
- Интерактивный редактор прав доступа (спецстраница).
- Возможность создания страниц вместе с защитой.
- Защита страниц.
- Защита категорий.
- Защита пространств имён.
- Защита семантических свойств.
- Возможность включения прав друг в друга.
- Определения прав доступа на вики-страницах в специальном пространстве имён.
- Группы пользователей, возможность включения групп в группы. Не стандартный MediaWiki-механизм групп (sysop, bureaucrat и т. п.), а собственный механизм, хранятся также на вики-страницах.
Защита механизмов доступа
На странице Security issues with authorization extensions описаны следующие механизмы, которые для тех или иных реализаций прав доступа могут представлять собой «дыру». Относительно IntraACL их статус следующий:
- ✓ Включение страниц — если страница недоступна для чтения, всё выглядит так, как будто её нет. Текст при этом можно заменить на пустой.
- ✓ Предзагрузка текста при правке с другой страницы — текст заменяется на «доступ запрещён».
- ✓ Экспорт/импорт — недоступные статьи не экспортируются и не могут быть перезаписаны импортом.
- ✓ Ленты свежих правок — недоступные статьи не отображаются в лентах.
- ✓ Списки, поиск — аналогично, в списках недоступных статей нет.
- ✓ Diff’ы, история
- ✓ api.php?action=query
- ✓ Сырой/печатный вид
- ✓ Связанные права
- ✓ Доступ не даётся создателю неявно
- ✓ Кэширование
- ✓ Перенаправления
- ✓ Правка секций
- ✓ Другие расширения — если совместимы с IntraACL/HaloACL. Все расширения из состава Mediawiki4Intranet — совместимы.
- ✕ Прямой доступ к содержимому загруженных файлов — пока что не защищается, так как требует интеграции прав с веб-сервером.
- ✕ Слежение за страницами — если пользователь раньше следил за страницей, а потом она была закрыта, ему всё равно будут приходить сообщения с дифами.
Основные отличия
Редактор
thumb|right|200px|Редактор прав HaloACL В HaloACL интерфейс служебной страницы реализован неудобно, глючит и тормозит, на основе JavaScript-фреймворка YAHOO UI (в жизни к нему теперь не притронусь). Кроме того, он переусложнён (можно написать раз в 5 меньше кода), и ужасен с точки зрения удобства пользователя — он пошаговый и не очень интерактивный.
thumb|right|200px|Редактор прав IntraACL В IntraACL интерфейс гораздо дружелюбнее и написан на «голом» JavaScript’е, без использования каких-либо фреймворков вообще (кроме МедиаВиковского AJAX’а — sajax_do_call), посему работает очень шустро и приятно. Аналогично реализован и редактор групп, и списка шаблонов быстрого доступа.
Пример
Пример создания прав в редакторе HaloACL:
- Сначала нужно выбрать, что создаём — права, шаблон, или «личный шаблон».
- Потом выбрать на что создаём права — на страницу, категорию, namespace, свойство. Опция «свойство» не скрывается, даже если Semantic MediaWiki не установлена.
- Ввести имя и нажать «Далее». После этого поменять имя, естественно, уже нельзя.
- Нажать «Create right». Откроется страшная форма с кучей полей.
- Ввести имя и описание для «права». То есть словесное описание. Зачем оно — понятия не имею.
- Выбрать права галочками.
- Выбрать «кому» из 5 вариантов («мне», «набору юзеров/групп», «всем», «всем зарегистрированным», «всем анонимным»).
- Выбрать галочками, кому же всё-таки, в случае набора. Выбор ведётся из YUI TreeView, фильтруемого тут же, и со страшной силой тормозит.
- Чтобы просмотреть, кому что-то выдано сейчас, надо переключиться на другую вкладку.
- После этого нажать «Сохранить право». Но если вы думаете, что квест закончен и всё сохранилось, очень ошибаетесь.
- Нажать «Далее».
- Ещё одной такой же формочкой задать права на изменение самих прав.
- Нажать «Далее».
- Нажать «Сохранить».
Только после этого ваши права сохранятся. При всём этом процессе увидеть, какие реально получились права с учётом всех включений шаблонов и групп нельзя. Также нельзя увидеть реальный текст определения, который в действительности сохранится на страницу прав. Также в оригинале плохо работает и само сохранение — иногда оно сохраняет текст определения, но не разбирает его на права и они в итоге не действуют.
В IntraACL, с другой стороны, редактор интерактивный, не пошаговый и всегда показывает то, что будет сохранять.
- В любой момент можно поменять, что защищаем, добавить права, права на изменения прав или включения шаблонов.
- Везде работает автозаполнение (autocomplete) — подсказывает страницы, пространства имён, категории, пользователей, группы.
- При выборе пользователя или группы состояние флажков (✓) меняется так, чтобы отражать текущие права выбранного пользователя/группы.
- Причём, редактор подгружает включаемые определения групп и шаблонов и вычисляет реальные права, учитывая, если право было дано пользователю, потому что он находится в группе или если право дано через шаблон.
- Дать или отобрать права очень легко — нужно просто отметить или снять флажок. Текст определения прав при этом изменится.
- Кнопка «Сохранить» ровно одна :)
Панель
Переделана панель, появляющаяся при редактировании страниц:
- Не требует тяжёлого JavaScript’а.
- Сохраняет состояние при нажатии «Предпросмотра».
- Показывает ссылки на шаблоны быстрого доступа, чтобы можно было просмотреть их содержимое.
- Подсказывает, какие ещё права действуют на страницу (то есть права на пространства имён и категории).
- Подсказывает, когда вы не можете редактировать права страницы.
Право 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’иться, а также позволяют массовое редактирование и импорт/экспорт (то есть редактирование нескольких страниц за запрос). Разрешается изменение некорректных определений, дабы если что, пользователям не приходилось тут же бежать к админам.
Общие черты
Все определения прав, групп и т. п. хранятся как вики-страницы в специальном пространстве имён ACL.
Также полностью совместим интерфейс для расширений (метод 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, но не разрешать просто) и ликвидированы.