Как структурировать нескольких пользователей с несколькими уровнями разрешений?

Question

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

Это типы пользователей:

• Пользователь
• Средство утверждения
• Администратор объекта
• Корпоративный утверждающий
• Корпоративный администратор

Теперь есть также возможности, и именно здесь эти уровни разрешений вступают в игру. Объекты связаны с пользователями и уровнями пользователей в виде таблицы:

user_id     facility_id     userlevel
joebob      ABCInc          Facility Admin

Пока все довольно просто, но теперь я хочу позволить одному пользовательскому уровню устанавливать ограничения на другом пользовательском уровне для определенного объекта. Например, я администратор объекта и хочу разрешить пользователям отправлять только определенные формы. Как бы я сохранил это?

Я думал о новой таблице, которая связывает unit_id, userlevel иmissionslevel. Но каким именно будет уровень разрешения? Int? Или я бы добавил столбцы в таблицу, такие как canOrderThings или canSearchForStuff?

Я видел, как это будет работать, но кажется, что это будет немного грязно и трудно отследить, если у вас есть большое количество разрешений. Как бы вы добавили уровни разрешений, не выбрасывая все из дурака? Или даже установка уровней разрешений была бы немного сложной, я думаю.

Кроме того, пользовательские уровни напрямую связаны с пользователями в Таблице пользователей, но для этих серверов используются разные цели.

Есть ли лучший способ структурировать все это?

Answer 1

Хорошей идеей является использование второй таблицы параметров. Некоторые форумы используют этот метод.
Каждому из ваших пользователей присваивается UserGroupId, который обычно является Int, поскольку с ними легче всего работать. Например, UserGroupId из 1, может быть администратором, 2 может быть учителем (зависит от вашей организации).

Тогда у вас есть таблица с именем Permissions, в эту таблицу вы включаете все параметры в виде столбцов, что-то вроде этого.

UserGroupID --|-- SearchEnabled --|-- CanOrder
             1                   0           1
             2                   1           1

Используя простую двоичную систему, 1 включена, 0 отключена, вы можете управлять параметрами для каждой группы пользователей. Это позволяет получить все разрешения с помощью одного запроса, но при этом предлагает очень большую область для настройки.

Вам не обязательно использовать двоичные числа. Например, вы можете использовать значения 1,2,3, где 1 - полное разрешение, 2 - частичное, а 3 - ноль. Это зависит от того, насколько конкретными должны быть ваши правила.

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

If ($user['SearchEnabled')
{
   $generate->SearchOptions();
}
else 
{
   $generate->Error('NoSearchPermissions');
}

Использование двоичных чисел имеет очевидное преимущество, если просто проверить, ИСТИНА или ЛОЖЬ. Если вы используете другую систему нумерации, это потребует немного больше работы, проверяя конкретное значение
If ($user['SearchEnabled'] == 2 || $user['SearchEnabled'] == 1)

Answer 2

Ну, если бы я хотел реализовать разрешения в своем приложении, я мог бы сделать это 3 способами (я могу думать на макушке):

1. В таблице пользователей (и записи, если вы используете orm) укажите уровень int. Так, например, пользователь уровня 1 может только просматривать формы, уровень 2 может публиковать сообщения, уровень 3 - администратор и может редактировать и т. Д. Затем в представлениях вы просто проверяете, какой уровень есть у пользователя, и отображаете форму, которую они могут редактировать и т. Д. (Исходя из вашего вопроса, я полагаю, это то, что вы уже делаете)

   Плюсы:

   • Простота настройки
   • Позволяет группировать разрешения вместе.

   Минусы:

   • Если вам нужен уровень от 1 до 2, вам придется проделать большую работу. Так что сложнее добавить уровни между ними.

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

   Плюсы:

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

   Минусы:

   • Вы не можете группировать разрешения, но я полагаю, что вы можете просто назначить их всем сразу, если хотите.
   • Это больше работы, чтобы сказать пользователю, что он / она, потому что вы можете только перечислить все разрешения или сделать массовое переключение, чтобы определить, являются ли они администратором или нет. (Например: я обычный пользователь? Я могу редактировать формы, но не искать?)

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

   Плюсы:

   • Вы можете добавлять столько раз, сколько хотите, не выбрасывая что-либо из вейк. Типы типа "супер администратор" или "несколько менее администратор"

   Минусы:

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