SECURITY - механизмы безопасности в Zope
Zope предоставляет программистам и администраторам простые, и в то же время мощные и гибкие механизмы управления безопасностью. Безопасность в Zope стоит на трех китах, трех базовых понятиях - пользователь, роль, и вид доступа.
Вид, или тип доступа определяет программист при создании компонента. Каждому классу в компоненте определяется полномочие "Add" ("Добавить экземпляр класса в дерево объектов"), каждому методу класса можно определить свои собственные полномочия, которые определят, кому и какой вид доступа предоставлен к этому методу класса. Например, методу index_html (который вызывается при обращении к объекту, а не к конкретному методу) обычно дается вид доступа View. Но это дело программиста, как назвать свои полномочия, и какие методы какими полномочиями защитить. Обычно методы объекта объединяются в группы, предоставляющие один сервис. Например, класс НовостеваяЛента может иметь сервисы (группы методов) "показ новостей", "добавление новостей", "редактирование новостей", "удаление новостей", "добавление/редактирование/удаление рубрик". И каждый из сервисов можно защитить (дав ему отдельный вид доступа) - с точностью до одного метода. Для более тонкого управления, уже внутри метода, программист может запросить SecurityManager - "имеет ли текущий пользователь права на создание DTML Методов в Папке Razdel?"
Роли создает администратор сайта через менеджерский web-интерфейс Zope. Понятие роли распространяется не на весь сайт, не на ZODB, а на часть дерева. Администратор создает роль в какой-то папке, и дальше благодаря механизму acquisition эта роль распространяется вниз по поддереву.
Zope, поставленная из дистрибутива, имеет 3 роли, определенные в корне ZODB - Anonymous, Owner и Manager. Manager - это такой всесильный администратор, аналог рута. Owner - владелец тех ресурсов, которые он создал. Анонимный пользователь - просто посетитель сайта; ему изначально доступны типы доступа: Access content, View, Use SQL Methods (это для того, чтобы позволить вызывать SQL Методы из DTML Методов) и Search ZCatalog.
Администратор сайта в дальнейшем может создавать новые роли, как в корне, если у самого администратора есть права на редактирование корня, так и в любых поддеревьях, на которые у администратора есть права.
Эти 2 механизма - категории доступа и роли - совершенно ортогональны, и в web-интерфейсе образуют табличку из сотен checkbox'ов - какой роли какие категории доступа.
Администратор сайта может, например, завести роли Editor и ChiefEditor, и дать роли Editor права на редактирование DTML Document'ов, а роли ChiefEditor - права на редактирование DTML Method'ов, картинок, и на создание папок.
Дав роли SubAdmin права на администрирование безопасности в поддереве сайта, администратор эффективно делегирует полномочия. Пользователи (то есть записи о пользователях) - это объекты (как и все остальное), экземпляры класса User. Изначально Zope ставится с компонентом UserFolder, который хранит эти объекты в ZODB, и может получать и проверять username/пароль только по схеме Basic Authentication. Но компонентная технология и здесь дает свои преимущества. Уже доступны компоненты:
- etcUserFolder, который берет данные из файла; формат файла угадайте сами :)
- UserDB - хранит записи о пользователях в SQL; ходит за ними в SQL не сам, а пользуется стандартным слоем абстракции ZSQL, так что может ставиться на любой SQL-сервер (к которому у Zope есть адаптер)
- RadiusUser, MysqlDB, NTUserFolder, NISUserFolder - ну, про этих все очевидно
- GenericUserFolder - позволяет программисту самом писать процедуры аутентификации
- LoginManager, Membership - более продвинутые, но менее отлаженные варианты GUF; части Zope Portal Toolkit
