Вот два моих смысла, чего бы это ни стоило.
Сначала я бы сказал, когда вы начинаете проектировать это, подумайте об ООП и о том, как оно будет применяться к сущностям в системе.Пользователи, User_Role, Roles, Role_Permissions, Accounts, Account_Types, Account_Type_Features и т. Д.
USERS: - Должно быть разрешено использовать OpenID, когда он набирает обороты - Возможность выбора между идентификаторомили UUID для переносимости базы данных
РОЛЬ ПОЛЬЗОВАТЕЛЯ: (не РОЛИ УЧЕТНОЙ ЗАПИСИ) Я бы посоветовал вам быть очень конкретным здесь.Например, где вы проводите грань между опытным пользователем и администратором?В чем разница между ADMIN и ВЛАДЕЛЕЦОМ?Пока они четко определены (и не размыты), это будет работать.Если есть какие-либо вопросы среди вашей пользовательской базы, довольно скоро у вас будет сложный набор ролей и разрешений.Я бы свел это к минимуму, чтобы все было чисто.Пользователи поймут, как работать с тем, что им дают.Кроме того, я бы изменил это на РОЛИ ТИПА ПОЛЬЗОВАТЕЛЯ.Роли должны применяться к пользователю, а не к учетной записи.
РАЗРЕШЕНИЯ НА РОЛЬ: (не РАЗРЕШЕНИЯ НА ТИП АККАУНТА) Это должно быть изменено на РАЗРЕШЕНИЯ НА РОЛЬ.Разрешения распространяются на роль пользователя, а не на учетную запись или пользователя.По моему опыту, чем яснее дизайн, тем меньше места для путаницы в будущем.Кроме того, избегайте ACL, как чума.Сделайте это простыми отношениями один к одному.Мне еще предстоит найти причину для реализации ACL для любой веб-системы.Другие системы, основанные на разрешениях, намного легче понять, поддерживать и использовать.Нет смысла усложнять этот вопрос.
ОСОБЕННОСТИ ТИПА УЧЕТНОЙ ЗАПИСИ: Будьте осторожны, чтобы не затенить Разрешения типа учетной записи и Функции типа учетной записи.Ваша первая точка маркера использует слово permissions.Измените это на особенности.Тип учетной записи активирует более расширенные / расширенные функции (не разрешения).
Управление разрешениями: Для приложения без сохранения состояния, запущенного в Интернете, сеансы - это путь.Преимущество заключается в том, что нет обходных путей к БД, чтобы постоянно проверять, авторизован ли пользователь.
Permission::require() должен следовать тем же определениям параметров, что и сеансы.Это предотвратит перекрытие других подмножеств разрешений.Таким образом, вызов будет выглядеть примерно так: Permission::require('User Management', 'Add User'); Это означает, что он будет искать $_SESSION['All Permissions']['User Management']['Add User'] Это предотвратит неоднозначность.
Помните, что SIMPLE ЛУЧШЕ.