Создайте лучшую систему управления доступом

Глядя на разрешения типа вашей учетной записи, кажется, что вы имеете в виду структуру системы в стиле списка контроля доступа (ACL).

Если вы хотите сделать его сверхгибким и потрясающим, то я бы посоветовал не хороший дизайн. Система ACL работает с простыми разрешениями - и, возможно, это действительно нормально в вашем сценарии, - но как только правила предоставления разрешений становятся хотя бы малейшими динамическими, то есть полагаться на любые контекстные данные, выходящие за рамки личности или ролей пользователя, - падение ACL плоский быстро.

В этом видео подробно рассказывается о недостатках ACL и обсуждаются альтернативные способы реализации контроля доступа с учетом реальных ситуаций.

Кроме того, это уже делалось раньше (хотя на удивление мало реализаций, на которые мы можем взглянуть); возможно, посмотрите Rhino Security . Исходная ссылка http://ayende.com/Blog/category/548.aspx не работает, поэтому сохраните ссылку на архив в Интернете для справки.

У меня нет никаких конкретных советов, но две системы, с которыми я знаком, которые имеют очень хорошие системы гибкого доступа / разрешений, - это Drupal и Plone. Вы могли бы сделать гораздо хуже, чем скопировать то, как работает любой из них. У них за плечами годы испытаний в реальных условиях.

Я бы посмотрел на систему Java на предмет разрешений:

http://download.oracle.com/javase/6/docs/api/java/security/Permission.html

Он использует "импликацию" логика »; то есть объект разрешения - это то, что решает, разрешено ли данное действие (то есть, подразумевают ли разрешения доступ к ресурсу). Я также хотел бы проверить BasicPermission, поскольку он имеет довольно простую спецификацию пространства имен для разрешений. В вашем примере это будет (согласно номенклатуре CRUD)

• user.create
• user.delete
• file.read
• file.create

В нашем веб-приложении мы назначаем разрешение каждому ресурсу или процедура, которую можно запросить, и набор разрешений для каждого пользователя. Затем мы выполняем логическое значение

isAuthorized = user.permissions.implies (requestedResource.permission); (подразумевается стандартная инкапсуляция)

, чтобы определить, разрешен ли доступ пользователю.

Зед Шоу сказал несколько интересных вещей о ACL и их ограничениях. Определенно стоит посмотреть, прежде чем идти дальше по этому маршруту.

http://vimeo.com/2723800

Один из способов, который я видел и который мне нравится, это своего рода "каскадные" разрешения. У вас есть основной набор разрешений - скажем, чтение, запись, удаление - и они могут быть назначены группе или пользователю.

READ    USER1
READ    USER2
WRITE   USER2
READ    USER3
WRITE   USER3
DELETE  USER3

В качестве альтернативы вы можете указать "группу" вместо имени пользователя.

READ    SUBSCRIBER
READ    EDITOR
READ    ADMIN
WRITE   EDITOR
WRITE   ADMIN
DELETE  ADMIN
USER1   SUBSCRIBER
USER2   EDITOR
USER3   ADMIN

А затем вы можете просто использовать значения в таблице для сортировки и поиска записей. Это позволяет быть членом нескольких групп с взаимоисключающими правами и т. д.

Вот мои два смысла, чего бы он ни стоил.

Во-первых, я бы сказал, когда вы начинаете проектировать это, подумайте об ООП и о том, как это будет применяться к объектам в системе. Пользователи, Роль_пользователя, Роли, Права_Ролевые, Учетные записи, Типы_счетов, Свойства_Счета_Счета и т. Д.

ПОЛЬЗОВАТЕЛИ: - Следует разрешить использование OpenID, поскольку он набирает обороты - Возможность выбора между ID или UUID для переносимости базы данных

РОЛИ ПОЛЬЗОВАТЕЛЯ: (не РОЛИ ТИПА УЧЕТНОЙ ЗАПИСИ) Я бы посоветовал вам быть здесь очень конкретным. Например, где вы проводите грань между опытным пользователем и администратором? В чем разница между ADMIN и OWNER? Пока они четко определены (а не размыты), это будет работать. Если среди вашей пользовательской базы возникнут какие-либо вопросы, довольно скоро у вас будет запутанный набор ролей и разрешений.Я бы свел это к минимуму, чтобы все было в чистоте. Пользователи поймут, как работать с тем, что им дают. Кроме того, я бы изменил это на РОЛИ ТИПА ПОЛЬЗОВАТЕЛЯ. Роли должны применяться к пользователю, а не к учетной записи.

РАЗРЕШЕНИЯ НА РОЛЬ: (кроме РАЗРЕШЕНИЙ НА ТИП УЧЕТНОЙ ЗАПИСИ) Это должно быть изменено на РАЗРЕШЕНИЯ НА РОЛЬ. Разрешения распространяются на роль пользователя, а не на учетную запись или пользователя. По моему опыту, чем четче дизайн, тем меньше путаницы в будущем. Также избегайте ACL как чумы. Сделайте это простыми отношениями один на один. Мне еще предстоит найти причину для реализации ACL для любой веб-системы. Другие системы на основе разрешений намного проще понять, поддерживать и использовать. Нет смысла в усложнении дела.

ОСОБЕННОСТИ ТИПА УЧЕТНОЙ ЗАПИСИ: Будьте осторожны, чтобы не скрыть разрешения типа учетной записи и функции типа учетной записи. В вашем первом пункте используется слово «разрешения». Измените его на функции. Тип учетной записи активирует более продвинутые / премиум-функции (не разрешения).

Управление разрешениями: Для приложения без сохранения состояния, работающего в Интернете, сеансы - это лучший вариант. Преимущество заключается в том, что нет необходимости постоянно обращаться к БД. проверьте, авторизован ли пользователь.

Permission :: require () должен следовать тем же определениям параметров, что и сеансы. Это предотвратит перекрытие других подмножеств разрешений.Таким образом, вызов будет выглядеть примерно так: Permission :: require ('User Management', 'Add User'); Это означает, что он будет искать $ _ SESSION ['Все разрешения'] ['Управление пользователями'] ['Добавить пользователя'] Это предотвратит двусмысленность.

Помните, ПРОСТОЕ ЛУЧШЕ.

Я советую вам изучить Zend_Acl от Zend Framework. Как и у большинства пакетов Zend, у него крутая кривая обучения. Но когда вы полностью понимаете взаимосвязь ресурсов, действий и ролей, они становятся очень универсальной и мощной основой для ваших собственных реализаций ACL.

Изучите существующие пакеты и шаблоны ACL.

Семантика, которую вы используете, немного запутана. Например, типы учетных записей "Владелец", "Администратор", "Опытный пользователь", "Гость" больше похожи на "Типы пользователей".

Также, возможно, вы могли бы сделать то, что вы называете "AccountPermissions", подклассом Account. Таким образом, в зависимости от типа учетной записи, будут применяться различные разрешения.