YuriMakarov /09.07.2003 13:22/ Неплохо бы в редакторе добавить несколько кнопочек (типа как в UBB) для вставки макросов и возможно символов форматирования текста. Понятно, что все это несложно и руками набрать, но не всегда эти комбинации помниш (особенно если новичек) и плюс приходится между регистрами переключаться. Наверное это с помощью JavaScript
YuriMakarov /09.07.2003 13:27/ Наблюдение за страницами
Создавая новую страницу обычно хочется за ней понаблюдать некоторое время (если она доступна для редактирования другим). Может есть смысл сделать так – все вновь созданные страницы автоматом включаются в наблюдаемые автором, или наследовать признак наблюдения в кластере от родительской страницы.
Предложения по безопасности
Поддержка групп пользователей
В системе отсутствуют возможности создания Групп пользователей для разграничения полномочий. Это очень неудобно в работе, когда есть потребность в таком разграничении. При желании изменить полномочия на группу страниц (необязательно кластер) приходится все в ручную править. То же самое при появлении нового пользователя с некоторым набором полномочий.
Эту задачку можно очень просто решить.
Достаточно ввести в ACL еще один тип пользователя (в дополнение к * и $),
это ссылка на конкретную страницу. Она означает «Взять права доступа со страницы».
Редакт: @ACL/Редакторы – редактируют только из списка редакторов.
Чтение: @Yuri Makarov / My Club / Members? – чтение только членам моего клуба.
Чтение: @Project 1 / Members? – чтение только учасникам проекта Project 1?.
Чтение: !@Black List? – запрет на чтение пользователям внесенным на страницу Black List?.
Достоинства этого метода
Простота реализации – подправить код только в месте проверки полномочий (сделать сборку полномочий рекурсивной, это наверное несколько строчек добавить). Все остальное – заведение/редактирование списков доступа (групп пользователей), описание списков доступа, ограничения доступа к ним и их редактированию – все это делается уже имеющимися стандартными средствами.
Возможность создания произвольных групп доступа в любое время через веб-интерфейс.
Возможность создания групп доступа любым пользователем системы (для своих нужд к примеру).
Возможность маскировки групп доступа. Если не дать кому-то прав на чтение страницы с описанием группы доступа, то он может даже не подозревать о ее существовании.
Возможность изменения прав пользователя сразу на большую группу страниц, скажем добавив или убрав пользователя из My Club / Members? я разрешаю/запрещаю ему доступ ко все моим закрытым страницам.
Возможность изменения поступа ко всем страницам кластера (и не только) из одного места, с сохранением возможности индивидуальной настройки доступа к отдельным страницам кластера. Для этого достаточно в поле доступа страницы (к примеру Кластер 1 / Стр 11?) поставить ссылку на главную страницу кластера (Кластер 1?) или на отдельную страницу с описанием группы доступа к кластеру (Кластер 1 / Members?)
Тут еще много примеров придумать можно.
Этот метод управления полномочиями исключительно гибкий.
Реализация
Для реализации этого метода нужно в месте проверки прав доступа к странице добавить предварительную обработку (рекурсивную) списка доступа.
Если список доступа содержит группы, типа @Project 1 / Members?, то вставить в это место список доступа к Project 1 / Members?. Т.е. это выглядит как рекурсивный вызов той же процедуры.
В этом рекурсивном алгоритме обязательно должен быть контроль зацикливания.
Т.е. если список доступа текущего обрабатываемого документа уже встречался выше, то его обработка не делается (сделана выше).
Для этого можно использовать контрольный список.
Первоначально контрольный список пуст.
Перед обработкой прав доступа в конец контрольного списка заносится имя текущего документа.
Если в списке доступа есть группа отсутствующая в контрольном списке, то вставить список доступа для соотв. документа.
Использование такого алгоритма
позволяет избежать бесконечных циклов по правам (их легко сделать по ошибке) и
позволяет в корневом документе кластера, в правах доступа, указать ссылку на самого себя. При этом все вновь создаваемые документы кластера будут автоматом наследовать права из корня и следовательно будут наследовать ссылку на права к кластеру.
Контроль доступа к Экшенам и другим элементам
Сейчас Экшены (и возможно другие элементы системы) беззащитны перед любым пользователем. Если у меня есть право хоть чтото написать в систему (напр. коммент), я могу посмотреть очень многое, даже если хозяин системы запретит смотреть каталог, изменения, списки пользователей и т.д. Мне достаточно вставить в коммент вызов любого экшена.
Эта проблема тоже решается просто.
Достаточно в начале Экшена проверить права доступа пользователя к некоторой связанной и экшеном страницей. С какой страницей большого значения не имеет, к примеру можно завести кластер Actions и в нем страницы Actions / Resent Changes? и т.д. На самой странице описание экшена, в правах доступа – права пользователей на исполнение.
При этом можно разграничить доступ к результатам работы экшена в зависимости от прав читателя на страницу (или ее владение), поскольку мы можем задать 3 списка доступа к каждому экшену.
Это позволяет скажем запретить всем (кроме определенной группы) видеть результат экшена в комменте, или еще какие варианты (пока не обдумал).
Переделки минимальные, контроль полный и в онлайне с веб-интерфейса.
Можно скомбинировать с поддержкой групп доступа.
Предложения по Upload
Сейчас есть несколько экшенов для загрузки файлов (картинок) на сайт,
но то, что я видел, меня не устраивает. Недостатков несколько.
Как минимум:
Отсуствие разграничения полномочий – кто может загружать/скачивать файлы/картинки.
Отсуствие прав доступа к файлу – чтение/перезапись/удаление.
Проблема с именами. Может быть много файлов с одинаковым именем. Вводить коды для имен – плохо.
Можно довольно просто решить эти проблемы.
(to be continued ..)
Предложения по форматерам
В wakka.php в папке форматеров сделать преобразование кода языка к нижнему регистру.
