В этой статье я расскажу вам о способе организации прав доступа к веб-ресурсу на основе ролевой модели.
Сразу отмечу, что я не буду приводить здесь реализацию приложения для получения или проверки прав на каком-либо из языков программирования, а остановлюсь лишь на инфологической модели базы данных.
Грамотную организацию хранения такой информации я считаю наиболее важной, поскольку гибкая модель, соответствующая заявленным требованиям, позволит в будущем легко и безболезненно расширять систему, а также без труда внедрять ее в любых условиях.
веб-ориентированных языков.
Предлагаемый мною метод аналогичен популярной организации прав доступа, изложенной в phpGACL .
Итак, данный способ реализации подойдет вам, если:
1) Вы хотите иметь возможность получать права доступа пользователей к конкретному объекту системы, в том числе для каждого конкретного пользователя; 2) Вы хотите организовать пользователей таким образом, чтобы каждый из них принадлежал к субъекту, в рамках которого он имеет определенный набор прав, а также чтобы пользователь имел возможность принадлежать сразу к нескольким субъектам; 3) Было бы здорово, если бы некоторые пользователи внутри субъекта могли управлять правами доступа других пользователей внутри этого же субъекта без участия администратора, при этом сами такие пользователи не выходили бы за рамки прав своего субъекта; 4) Вам хотелось бы, чтобы система организации была интуитивно понятной и имела простую организацию на любом из языков программирования, предназначенных для веб-разработки, а также чтобы ее хранение можно было организовать в любой из реляционных баз данных; 5) В будущем перед информационной системой встанет задача протоколирования действий пользователей, и хотелось бы иметь прямую связь между системой прав доступа и системой протоколирования.
Перейдем к рассмотрению практического примера:
Задача состоит в том, чтобы организовать систему управления проектами, например, так: Система:- Администратор;
- Контент менеджер.
- Руководитель проекта;
- Куратор проекта;
- Заказчик проекта;
- Аналитик проекта;
- Исполнитель проекта;
- Тестер проекта.
Рассмотрим модель базы данных, реализующую хранение системы прав:
Что мы имеем: 1) объект – объект доступа; 2) действие – действие, совершаемое объект ; 3) разрешение – разрешение на совершение действия над объектом.
объект ; 4) пользователь – пользователь; 5) проект – проект (в других ИС может быть «партнер», «контракт» и т.п.
); 6) project_type – тип проекта; 7) user_assigment – назначение пользователя пользователь к конкретному проекту проект ; 8) роль – роль для типа проекта.
тип_проекта ; 9) role_permission – назначение разрешений разрешение роли роль ; 10) role_user_assigment – назначение назначения пользователю-проекту user_assignment конкретная роль; 11) Remove_permission_user_asgmt – удаление разрешения разрешение специфическое связывание user_assignment .
Далее рассмотрим последовательность наших действий:
1) В соответствии с задачей у нас есть 2 типа проекта: пользовательский проект и системный, их закрепляем в тип_проекта .2) Также у нас есть 2 роли для типа «система» и 6 ролей для типа «пользовательский проект», исправим их в роль под соответствующим тип_проекта .
3) Далее определяем объекты объект , с которым будут работать пользователи.
(например, «профиль пользователя», «задача», «тестирование», «заметка» и т. д.) 4) Определить действия действие произведено для всех объект .
Это как классические CRUD, так и системные: «назначить», «блокировать», «загрузить» и т. д. 5) Формируем коллекцию разрешений от определенных действий и объектов разрешение , например: «Добавить задачу», «Редактировать заметку» и т. д. 6) Создать для конкретных ролей роль разрешения разрешение .
7) Далее остаётся только создать конкретных пользователей и проекты, связать первых со вторыми в user_assignment и назначьте им роли в рамках конкретного проекта в таблице role_user_assignment .
В этой системе нет такого понятия как бан, поэтому если у пользователя 2 роли, то его правами доступа будет считаться совокупность всех разрешений для этих ролей.
При этом, если необходимо, чтобы у пользователя не было какого-то конкретного разрешения из его прав, достаточно просто внести это в таблицу.
удаленное_permission_user_asgmt (что означало бы отсутствие таких прав доступа).
Например, для тестировщика нужно предоставить разрешение, которое есть только у роли «Менеджер проекта».
В этом случае тестировщику достаточно назначить роль «Менеджер проекта» и удалено_permission_user_asgmt введите все разрешения, кроме необходимых.
В рамках данной организации не представляет сложности предоставить право любому из пользователей проекта самостоятельно назначать роли пользователям внутри проекта, при этом он не сможет назначить ни себе, ни кому-либо другому права роли «системный администратор».
, потому что ему на выбор будут предоставлены только те роли и разрешения, которые с ним связаны тип_проекта .
Отмечу, что такая организация хорошо взаимодействует с системой логирования (в данную статью она не включена из-за простоты), поскольку мы можем узнать, какое действие совершил конкретный пользователь в определенный момент. Также такая система организации прав хорошо сочетается с системами уведомлений и системами потока задач.
Система использовалась 2 года в одной из бизнес-информационных систем (реализация приложения на PHP, база данных Oracle), где она подошла идеально.
Теги: #Права доступа #веб-разработка #разработка веб-сайтов
-
Замена Слов
19 Oct, 24 -
Объявлены Цены На Kinect
19 Oct, 24 -
Barcamp Central Asia 2009 В Прямом Эфире
19 Oct, 24 -
Краткое Введение В Структуру Moai
19 Oct, 24
