Разрешения для пользователей веб-сайта

Question

Я работаю над веб-сайтом, где каждый пользователь может иметь несколько ролей / разрешений, таких как базовый вход в систему, заказ продуктов, администрирование других пользователей и так далее. Помимо этого, есть магазины, и каждый магазин может иметь несколько пользователей, управляющих им. Каждый магазин также имеет собственный набор разрешений.

Я запутался и не уверен, как лучше представить это в БД. Прямо сейчас я думаю:

Пользователи роли users_roles магазины stores_users

Но нужно ли мне иметь таблицы store_roles и stores_users_roles для отслеживания отдельных разрешений для хранилищ или я должен ограничивать роли одной таблицей «ролей»?

Изначально я думал о том, чтобы иметь только одну таблицу ролей, но как насчет пользователей, которые имеют роли в нескольких магазинах? То есть, если пользователю дается роль, скажем, «обновления продукта магазина», должен быть какой-то метод определения того, к какому магазину это относится. Таблица store_users_roles могла бы исправить это, имея поле store_id, таким образом, пользователь мог иметь «обновление магазина» и «удаление продукта магазина» для магазина № 42 и только «обновление продукта магазина» для магазина № 84.

Я надеюсь, что здесь есть смысл.

Редактировать

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

Answer 1

Это, вероятно, очевидно для вас сейчас, но контроль доступа на основе ролей это hard . Я предлагаю не пытаться писать свои собственные, если вы не хотите, чтобы одна часть занимала все время, которое вы надеялись потратить на «классные вещи».

Существует множество гибких, тщательно протестированных библиотек авторизации, реализующих RBAC (иногда ошибочно обозначаемых как ACL), и я предлагаю найти такую, которая соответствует вашим потребностям, и использовать ее. Не изобретайте велосипед, если вы не фанат колес.

Answer 2

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

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

Например: StoreA может СОЗДАТЬ, ОБНОВИТЬ, УДАЛИТЬ клиента. и УДАЛИТЬ клиента можно сделать в StoreA, StoreB и StoreC.

Далее вы можете свободно ассоциировать пользователей с store_role_id в таблице user_store_roles.

Теперь запись user_store_role будет иметь user_id и store_role_id:

Коллекция

SELECT * FROM USER_STORE_ROLE WHERE user_id = @userID

возвращает все разрешенные операции пользователя во всех магазинах.

Для набора ролей пользователей в конкретном хранилище выполните внутреннее соединение перечисленного выше с таблицей user_store, добавив часть WHERE, например

где STORE_ROLE.store_id = @ storeID

Answer 3

Мне кажется, что если у меня есть разрешение на выполнение определенных ролей в наборе магазинов, то у меня, вероятно, будут одинаковые разрешения в каждом магазине. Так что одной таблицы ролей, вероятно, будет достаточно. Таким образом, «joe» может делать «хранить обновление продукта» и «хранить удаление продукта», а затем иметь таблицу user_stores, чтобы перечислить, к каким магазинам он имеет доступ. Предполагается, что для всего этого списка он будет иметь одинаковые разрешения во всех магазинах.

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

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

Если графический интерфейс действительно усложняется, я предлагаю вам взглянуть на него как с точки зрения магазина, так и с точки зрения пользователя. Другими словами, вместо того, чтобы выбирать пользователя, затем выбирать, какие разрешения у него есть, и к каким хранилищам они могут получить доступ, может * проще сначала выбрать магазин, затем выбрать, какие пользователи имеют доступ к каким ролям этот магазин. Зависит от того, сколько пользователей и сколько магазинов. В прошлом проекте я обнаружил, что намного легче сделать это одним способом, чем другим.

Answer 4

Положите store_id в таблицу user_roles.

Если это Rails, пользовательская модель будет have_many :stores, :through => :roles