У меня есть скрипт PHP со множеством запрещенных областей. В каждой из этих областей у меня есть функция, которая проверяет, имеет ли пользователь доступ к текущей области, проверив таблицу «usergroup». Эта проблема заключается в том, что у меня более 100 столбцов, поэтому я не уверен, что это правильный дизайн базы данных.Структура таблиц пользовательских прав
Я думаю, что это был неправильный подход.
Вы должны пошли на что-то вроде
USERGROUPS
UserGroupRules
UserGroupRuleLinks
Тогда можно было бы просто проверить, имеет ли группа соответствующее правило.
Есть люди, которые скажут вам, что вы работаете с структурой разрешений на основе ролей, но я предпочитаю бинарные разрешения самостоятельно. Еще в тот же день я бы использовал поле int, которое дало бы мне 32 разных флага, которые я мог бы установить. Таблица разрешений будет содержать имя и значение каждого флага, а таблица разрешений будет содержать все разрешения, применимые для каждого пользователя. Я также реализовал структуру групп и разделил поля разрешений на разрешение и отказ, что дало мне большую гибкость. По существу разрешения будет рассчитываться следующим образом:
AllowMask = userPermit.AllowPermissions;
DenyMask = userPermit.DenyPermissions;
foreach(groupPermit in groups.UserMemberOf(UserID))
{
AllowMask = AllowMask | groupPermit.AllowPermissions;
DenyMask = DenyMask | groupPermit.DenyPermissions;
}
Permissions = AllowMask & ~DenyMask
Оттуда это был простой вопрос получения значения флага и проверки Permissions & FlagValue > 0;
Как вы отметили в своем вопросе, однако вполне возможно, что 32 флаги Арен достаточно. Я столкнулся с той же проблемой и начал работать с полями varchar, которые содержали закодированные номера base64. Поскольку символы base64 содержат 6 бит, я бы просто удостоверился, что длины символов были несколько кратными четырем, поскольку 4x6 = 24/8 = 3. Это дало мне достаточно места для преобразования 4 кусков char в ints и выполнения над ними функции выше. Если флаг был больше 2^24, я бы просто отрезал 4 символа и работал с меньшим числом.
Надеюсь, что имеет смысл. Это своего рода запутанная система, которую можно внедрить, но как только она запускается, она дает разрешениям управлять мечтой.
Это классическая проблема, поскольку системы растут с течением времени. Модель начинается с полдюжины разрешений, и со временем она растет много раз, и в этот момент она становится уродливой и неуправляемой.
Я бы посмотрел role based access control. Вы определяете серию ролей, которые могут быть назначены вашим пользователям. Затем разрешения назначаются роли, а не пользователю. Это упрощает управление пользователями даже для людей с небольшим пониманием системы - вместо того, чтобы выбирать из сотен разрешений, они выбирают из небольшого числа ролей. Всякий раз, когда вам нужна более гранулярность, просто создавайте новые роли.
Это может выглядеть пугающим первый, но на самом деле вы смотрите на несколько таблиц:
Я реализовал базовую спецификацию RBAC несколько месяцев назад, и первоначальная ревизия заняла всего 3-4 дня для создания и реализации.
Это, казалось бы, было бы хорошо с точки зрения хранения, но это сделало бы его очень трудным с стороны maitainability/quering. –
Я думаю, что единственное основное препятствие, связанное с ремонтопригодностью, - это просто необычный подход. Тем не менее, надежный дизайн будет иметь смысл для всех, кто знаком с основами логической логики и кодирования base64. Кроме того, не все это сложно отвлечь все мелкие частицы от простых в использовании классов. Возможно, это не подходит для всех целей, но, по моему собственному опыту, я нашел, что он наносит очень удобный баланс между сложностью и гибкостью. –