Контроль доступа для нескольких пользователей в веб-приложении

Question

Я работаю над приложением PHP + MySQL для социальных сетей, теперь мне нужно настроить разные элементы управления доступом (чтение, создание, редактирование, удаление) для глобальных (все элементы) и / или собственных элементов (элемент, созданный самим собой). ) для каждого модуля для группы или конкретного пользователя.

У кого-нибудь есть предложения по этому поводу (структура таблиц и т. Д.)?

---

Хорошо, я предоставляю больше подробностей, в настоящее время у меня есть tbl_module, tbl_user и tbl_user_role. Каждый пользователь и роль могут иметь разные права доступа к определенному модулю.

• читать
• обновление
• создать
• удалить

и разделен глобальным доступом или только самостоятельно (собственная учетная запись или записи, созданные самим).

и мой текущий подход: я создаю другую таблицу для хранения деталей доступа:

• acl_uid
• mod_id (идентификатор модуля fk)
• target_id (идентификатор пользователя или роли пользователя)
• acl_type (пользователь / роль для определения ссылки на целевой идентификатор)
• acl_read
• acl_update
• acl_create
• acl_delete

диапазоны значений acl_read, acl_update, acl_create, acl_delete:

• 0 отказать
• 1 разрешить
• 2 относится к проверке с более низким приоритетом (если пользователь имеет значение 2, то ссылается на роль)
• 3 только для себя

Я считаю, что есть более эффективный способ решить эту проблему, или, может быть, улучшение моего нынешнего подхода.

спасибо за ваши ответы.

Answer 1

Это довольно широкий вопрос, поэтому вы, вероятно, получите только очень широкие ответы.

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

Другая таблица описывает, как отображается каждый тип контента (на главной странице, на отдельных страницах блога и т. Д.).

Другая таблица дает каждому пользователю один или несколько «типов пользователей» или «групп», таких как администратор, незарегистрированный, модератор и т. Д.

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

Я рекомендую вам потратить немного времени на изучение схем баз данных другого программного обеспечения CMS, например Slashcode , Drupal или одной из других миллионов систем CMS.

-Adam

Answer 2

Это на самом деле очень широкий вопрос. Предполагая, что у вас есть четкое разделение между уровнями приложений (например, с помощью MVC), это то, что происходит на бизнес-уровне.

Принимая ваши прямые требования, это может быть довольно просто. В вашей таблице пользователей есть hasEdit, hasView и т. Д. Для каждого элемента прикрепите к нему идентификатор пользователя, представляющий создателя. На бизнес-уровне правило заключается в том, что у них есть разрешение на редактирование, если они являются создателем или имеют hasEdit = true.

Поднимите это на ступеньку выше, если у вас есть разные типы, а разрешение hasEdit равно для типа , для этого вам понадобится другая сущность.

userPermission

• userPermissionId
• userId (FK)
• typeId (FK)
• hasEdit (логическое значение)
• hasView
• и т. Д.

Чтобы узнать, есть ли у них разрешение на редактирование, вы проверяете, являются ли они владельцем, или ищите этот тип элементов и текущего пользователя в таблице userPermission, и проверяете hasEdit. Вы можете создать дополнительные правила, например, поместить глобальный hasEdit в пользовательскую таблицу. Или представляющий глобальный hasEdit записью в userPermissionId с нулевым typeId.

Это может стать более сложным, с использованием ролей и переменного количества разрешений ... все это сводится к вашим требованиям. Вам нужно тщательно определить свои бизнес-требования (придумать кучу вариантов использования), и тогда вы сможете разрабатывать оттуда. Таким образом, на самом деле информации недостаточно для того, чтобы придумать ее больше, чем я изложил здесь (и даже это, вероятно, не совсем то, что вам нужно).

Answer 3

Существует довольно много способов проектирования безопасности, и мне понравилось немало для разных ситуаций. Есть UNIX-стиль user-group-other. Мне нравится модель безопасности PmWiki .

Я разработал веб-сайт, в котором использовалась структура разрешений ролей пользователей, аналогичная Apache . На этом веб-сайте я использовал систему шаблонов, в которой использовался файл заголовка и файл заголовка нижнего колонтитула, чтобы обернуть содержимое страницы «стандартным материалом». Страница с ограниченным содержимым может установить для переменной требуемое разрешение, которое ищет скрипт заголовка, и, если оно установлено, вызывает функцию авторизации, которая проверяет, принадлежит ли пользователю роль с таким разрешением.

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

Answer 4

Мне нравится использовать своего рода подход правил межсетевого экрана или аналогичный подход правил таблиц mysql: вы можете предоставить пользователям или группам пользователей определенные права на определенные объекты или группы объектов. Сделайте каждое правило строкой в ​​вашей таблице правил. Когда вам нужно выполнить какое-либо действие, такое как редактирование, вы можете выполнить внутреннее объединение в таблице правил для текущего пользователя, группы текущего пользователя, столбца логического редактирования и идентификатора объекта или группы объектов. Если вы вернете какие-либо строки, разрешение будет предоставлено.