Как структурировать разрешения пользователей для cms
Я создаю пользовательскую систему CMS для фотосъемки, и мне необходимо внедрить систему аутентификации и разрешений пользователей. Каковы обычные методы в отрасли для создания такой схемы.
В основном мне нужны пользователи, и пользователи могут быть разного типа. Некоторые пользователи, скажем, могут создавать только галереи, другие могут только редактировать их или редактировать только определенные галереи и т. Д. Итак, как это должно быть структурировано. Я использую базу данных MySQL и использую PHP для кодирования CMS.
Я попытался поискать в Google, однако нашел только статьи, в которых объясняется, как создавать пользователей для реальной базы данных MySQL. Я буду признателен за ссылку на статью, в которой объясняется, как следует делать подобные вещи.
Заранее благодарю вас.
1 answers
Существует два общих подхода к этой проблеме, оба предполагают разделение допустимых операций на нечто дискретное, что вы можете назвать. (Удаляйте сообщения, создавайте галереи, обновляйте код, сбрасывайте базу данных, запускайте ракеты, открывайте дверь гаража.) Предоставьте каждому из них растровое изображение в битовом векторе (если вы намерены иметь менее 32 разрешений, это хороший и компактный механизм хранения; если вы думаете, что он превысит 32 разрешения, размер типичного целого числа, тогда, возможно, таблица в вашей базе данных..)
Таким образом, вы можете либо напрямую сопоставлять пользователей с разрешениями ("Я хочу предоставить gallery_create sarnold"), либо вы можете сопоставлять пользователей и разрешения с помощью классов пользователей ("Я хочу предоставить gallery_create всем членам класса art_curator; затем я хочу повысить пользователя sarnold с docent до art_curator").
Если вы напрямую сопоставите пользователей с разрешениями, вы можете обнаружить множество странных разрешений в развертывании спустя годы. Если вы сопоставите пользователей с классами, вы можете обнаружить себя с искусственными классами пользователей, потому что вы доверили одному конкретному человеку привилегию, но не другие привилегии.
Поиск наилучшего способа решения этой проблемы все еще остается открытой проблемой; Я писал о различных типах моделей разрешений , моделирующих систему разрешений, в которой может быть слишком много или слишком мало информации, в зависимости от того, насколько сложной вы хотели бы сделать свою систему.
Если вы хотите просто хранить разрешения в растровых изображениях (например, реализация ядра Linux CAPABLE() для CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, и так далее) затем вы могли бы добавить новые привилегии с помощью чего-то очень простого:
if (requested_new_permission == "CAP_SYS_ADMIN")
user->permissions |= CAP_SYS_ADMIN;
else if (requested_new_permissions == "CAP_DAC_OVERRIDE")
user->permissions |= CAP_DAC_OVERRIDE;
...
Затем, когда вам нужно проверить возможности:
if (CAPABLE(user, CAP_SYS_ADMIN))
reboot_server();
И макрос CAPABLE() могут выглядеть следующим образом:
#определить СПОСОБНЫЙ (пользователь, cap) ((пользователь)->разрешения и (cap))
(Простите за C, я просто не очень хорошо знаю php; Я был вынужден исправить слишком много ошибок php, чтобы захотеть его изучить я сам.)
Если вы хотите сопоставить пользователей с разрешениями через классы пользователей, то это может быть три таблицы: таблица users, таблица groups или classes и таблица permissions. classes содержит столбцы для user_id и permission_id. Когда вам нужно проверить, может ли быть предоставлено разрешение, выберите класс пользователя, а затем выберите разрешение в классе. (Также прошло много лет с тех пор, как я писал SQL от руки; Я уверен, что один запрос может дать вам ответ "да" или "нет", но я не уверен, будет ли это несколько таблиц присоединиться или с помощью подзапросов, или просто было бы проще сделать два запроса к базе данных.:)
Надеюсь, это поможет.