контроллер — Как мне правильно управлять разрешениями пользователя на PHP?
Я прочитал о ACL (Списки контроля доступа) но я не понимаю, какой смысл использовать его больше, чем пирамидальный способ мышления. (Администратор контроллера расширяет модератора, который расширяет пользователя).
Каков наилучший способ сделать это? Это плохая практика, чтобы складывать расширения?
Решение
Во-первых, аутентификация.
Это только вход в систему и утверждение, что username / password комбинации связаны с пользователем X.
Во-вторых, авторизация.
Во-вторых, обычно все становится сложнее. Но для большинства случаев использования ваше общее понимание хорошо.
Пакеты как Zend \ RBAC или же Zend \ Acl являются хорошей отправной точкой для реализации авторизации в вашей доменной логике. Я предпочитаю RBAC, потому что есть более сложные реализации. Читайте об этом для более нюансов подходов.
С rbac пользователь играет роль (admin) который может наследовать от модератора, который также может наследовать от пользователя. В rbac роль уполномочена делать что-то, а не личность (user / principal на других языках). Где все может быть сложно, когда вы разрешаете редактирование комментариев. Только владелец может редактировать свои комментарии (per-entity rules). Но модератор может редактировать или удалять любые комментарии.
В приведенном выше пакете я использую собственноручное утверждение для авторизации для каждой сущности, поскольку это очень простой способ справиться с этим в этом пакете. Или вы можете иметь пользователя, который является администратором клиента X … но это не значит, что он является администратором клиента Y. Таким образом, ваши правила могут быть довольно сложными, помимо простой иерархии.
В этих случаях каждый пользователь, вероятно, будет иметь отношения многие ко многим с клиентами и связанными ролями для каждого.
Ваш isAllowed Метод должен был бы проверить на основе бизнес-критериев для этого. И это зависит от вашего домена — вот почему стратегии авторизации сильно различаются от проекта к проекту. Обычно это происходит, когда все становится сложным. В противном случае, большая часть разрешений времени не слишком сложна для понимания.
Другие решения
Стекирование расширений никогда не является проблемой, если объекты принадлежат друг другу и имеют родительское «значение». Так что Admin -> Moderator -> User -> Anonymous -> UserBase отлично подходит для авторизации.
Но, как Джулио уже упоминал, реализации этого широко и широко различаются в разных проектах, можно использовать пакеты или свернуть свои собственные (если они знают, что делают, в противном случае гораздо безопаснее использовать уже существующие пакеты, подобные упомянутым выше). )
detector