Как эффективно обрабатывать роли пользователей?

Question

Это немного расплывчато, так что вот мясные вещи:

Я видел системы аутентификации, которые выполняют одно из следующих действий

1. имеет отдельную таблицу ролей для каждой роли и отдельную таблицу разрешений, все пользователи в одной таблице
2. есть отдельная таблица для администраторов

я многое пропустил, я знаю. Но я действительно пытаюсь спросить:

Как мне создать свою базу данных на веб-сайте, на котором у меня много разных пользователей, и у каждого из которых разный доступ?

Как мне сделать так, чтобы мой сценарий был достаточно гибким, если я решу добавить другого типа пользователя с другими типами разрешений?

В настоящее время у меня есть класс User, и я планирую создать класс Administrator, который расширяет этот класс User. Или это немного излишне, когда я могу собрать их всех в одном классе и просто назначить необходимые разрешения?

Answer 1

вы можете иметь таблицы -

user (user_id, name ...)
permission (perm_id, name, desc)
role (role_id, title)
user_role (user_id, role_id)
user_permission (user_id, perm_id)
role_permission (role_id, perm_id)

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

Answer 2

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

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

Answer 3

Я думаю, вам нужно подумать о нескольких понятиях здесь. Первым будет список контроля доступа ( ACL ), а затем будет аутентификация.

В ACL вы определяете ресурсы , которые являются объектами, к которым вы хотите ограничить доступ, и роли , которые являются объектами, которые могут запрашивать доступ к ресурсу.

То, как я реализую свой ACL, использует Zend_Acl . У меня есть таблица под названием user_roles

user_roles('user_role_id', 'name', 'permissions', 'parent_role_id')`

У меня также есть таблица с именем user_role_maps, которая сопоставляет идентификатор пользователя с идентификатором роли пользователя. (Вы можете просто использовать это как столбец в пользовательской таблице, но это зависит только от того, как вы относитесь к нормализации ;-).) Затем я могу создать свой объект Zend_Acl из этой таблицы, а затем, когда пользователь аутентифицирован, я могу определить, к каким ресурсам они имеют разрешение и какие действия они могут выполнять над ресурсом. (Ресурс реализует Zend_Acl_Resource_Interface, поэтому его можно идентифицировать как Zend_Acl как ресурс.

Что касается аутентификации, это более простая концепция (на мой взгляд), вы, наверное, уже разобрались в какой-либо форме системы аутентификации, соответствующей токенам. Важным аспектом является использование идентифицированного идентификатора пользователя для определения его роли. Zend Framework также предоставляет пакет для этого в Zend_Auth .

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

Удачи.