Читайте также:
|
В предыдущем разделе рассмотрена возможность выборочного ограничения доступа к уже существующим документам. Однако Разработчик БД может встать перед той же необходимостью – разграничивать доступ к документам в зависимости от их типа и содержания – когда разрабатываемая база ни одного документа ещё не содержит.
Например, в Публичной АК пользователь имеет право редактировать свою учётную запись, не имеет права редактировать чужие учётные записи, и не имеет права создавать новые документы никаких типов. При этом создателем, т.е. фактическим автором своей учётной записи он не является, что не мешает ему тем не менее её изменять. Каким образом достигается такое гибкое сочетание прав доступа?
Ответ: не только документы, но и формы могут содержать список пользователей, групп и ролей (о которых - чуть ниже), которым разрешено:
Так, формой для создания пользовательских учётных записей разрешено пользоваться только членам группы «[UserCreator]». В каждой записи форма автоматически создаёт два невидимых поля типа «Авторы»: Owner и DocumentAccess. В первое из них записывается имя владельца учётной записи, во второе - название группы «[UserModifier]». Созданный документ, таким образом, смогут изменять только они и Редакторы базы.
Ещё одна защитная опция, которую форма устанавливает на поля в документе, запрещает редактирование поля, если пользователь имеет уровень доступа к базе ниже Редактора.
Упражнение 9.10
Какие поля в учётной записи в Публичной АК имеет смысл защищать от редактирования Авторами?
Роли
Допустим, программист разрабатывает некую базу-приложение общего назначения. Копии базы будут использоваться разными организациями, то есть круг пользователей заранее неизвестен даже приблизительно. Документы и оглавления внутри базы имеют раздельный доступ. Какие имена разработчик должен вписать в ACL, если ему неизвестна пользовательская иерархия организации, в которой база будет использоваться?
Вариант 1: придумать собственный набор групп, например, TeachDb.Boss, TeachDb.Teachers, TeachDb.Students. В документации к базе указать, что администратор Domino при инсталляции базы должен создать данные группы и заполнить их конкретными именами. Данный вариант имеет два недостатка.
Первый недостаток: имена групп для разных баз могут совпадать (вступать в конфликт), если разработчики сделали их простыми и короткими; в противном случае имена групп могут оказаться слишком длинными и трудными для запоминания.
Второй недостаток: при увеличении количества баз на сервере Публичная АК переполняется наборами групп, каждый из которых служит для обслуживания соответствующей базы. Зачастую группы, относящиеся к разным базам, будут логически эквивалетны и с одинаковым содержанием. Системному администратору будет всё сложнее ими управлять.
Для преодоления этих недостатков во многих информационных системах, и Notes/Domino в том числе, используется т.н. ролевой механизм. «Роль» («Role», «Группа доступа») - это псевдо-группа, определённая Разработчиком базы и хранящаяся в ACL. Роли используются для указания прав доступа к формам, документам и оглавлениям наравне с обычными группами и именами из Адресной Книги. Фактический пользователь проверяется на наличие у него той или иной роли только при операциях внутри этой базы. Разные базы, таким образом, могут свободно использовать одинаковые названия ролей.
Затем, когда база отдаётся из разработки в эксплуатацию, Управляющий базы редактирует ACL: заполняет её фактическими именами и названиями групп из Адресной Книги, после чего назначает им роли из представленного в базе списка.
Таким, образом, Разработчик задаёт состав ролей + уровни доступа для их обладателей. Управляющий задаёт наличие ролей у тех или иных фактических пользователей и групп.
Дата добавления: 2015-09-10; просмотров: 68 | Поможем написать вашу работу | Нарушение авторских прав |