Должен ли авторизация быть частью модели или контроллера?
Я пишу веб-приложение с некоторыми требованиями ACL: пользователь может вносить изменения в некоторые элементы, некоторые элементы могут быть редактируемыми несколькими пользователями, администратор может редактировать что-либо, и менеджер может редактировать Все в ее организации и т. Д.
Я использую игру! Рамки и внешности модуля модуля , кажется, место для создания проблем разрешения находится в контроллерах. Однако мне кажется, что проблемы авторизации являются частью бизнес-логики, и поэтому должны быть в модели. Кроме того, я начинаю видеть дублированную логику в контроллерах, которые мне нужно решить.
С другой стороны, добавление авторизации в модель означает, что мне придется иметь возможность получить текущий пользователь в рамках модели, что не кажется правильным. В качестве альтернативы, я мог бы добавить параметр «Current_user» на каждый метод модели, но это кажется еще хуже.
Так что такое обычная практика? Может / я должен поместить код авторизации в модели или держать его в контроллере?
3 ответа
Я думаю, что это серая зона. Можно утверждать, что доступ пользователя является частью отображения между миром HTTP и объектно-ориентированным миром. Это то, для чего предназначен контроллер (отсюда и интенсивное использование статики) для преобразования входящего запроса, готового к обработке бизнес-правил в доменной модели.
Я хотел бы предположить, что логика контроллера является абсолютно подходящим местом для управления доступом к модели, тем более что она управляется в основном на уровне аннотаций, а аутентификация абстрагируется от класса безопасности.
Авторизация не должна быть частью модели контроллера или домена.
Вместо этого он должен быть на уровне обслуживания.
Контроллер должен просто выступать в качестве диспетчера и делегата между HTTP и службой приложений. Это сервис приложений, где происходит оркестровка. Это лучшее место для размещения авторизации.
Предположим, что пользователь A авторизован для доступа к данным из домена X, но не авторизован даже для доступа на чтение данных из домена Y. Если авторизация размещена в контроллере, то пользователь A авторизуется в контроллере X и через вызовы службы могут получить доступ к данным из домена Y, что не соответствует ожиданиям.
Поскольку доменные модели взаимодействуют друг с другом на уровне обслуживания, следовательно, лучше всего разместить авторизацию на одном уровне.
Я нахожусь на этом этапе и намереваюсь справиться с этим следующим образом:
-
Нет проверки формы JS, вместо этого через HTTPS ajax
-
Ajax php class
-
Данные формы, отправляемые в модель в качестве ее данных для конкретной проверки для
общего типа, такого как электронная почта и пароль (вероятная проверка массива сопоставления будет использоваться другими классами, так что это определенно модельная область). -
если нет ошибок, поиск в таблице User учетных данных электронной почты / учетных данных пароля
, передаваемых контроллеру с типом аутентификации
, таким как логин / регистрация / сброс пароля -
Затем контроллер создает требуемый выходной вид или устанавливает пользователя, вошедшего в сеанс и т. Д.
Это основано на Laravel, но у меня есть собственная библиотека как хотите, чтобы он не зависел от laravel и просто свободно основывался на этом жизненном требовании.
Дело в том, что Модель ищет требуемые учетные данные как данные, а затем отправляет их в Контроллер, поскольку ему все равно, как их следует обрабатывать. Я думаю, что это единственный способ сделать эту область определенной ответственностью между каждым из компонентов.