Должна ли авторизация быть частью модели или контроллера?

Я пишу веб-приложение с некоторыми требованиями ACL: пользователь может вносить изменения в некоторые элементы, некоторые элементы могут быть доступны для редактирования несколькими пользователями, администратор может редактировать что-либо, а менеджер может редактировать все в своей организации и т.д.

Я использую Play! каркаса и внешнего вида модуля Secure, кажется, что место для решения вопросов авторизации находится в контроллерах. Однако мне кажется, что вопросы авторизации являются частью бизнес-логики и поэтому должны быть в модели. Кроме того, я начинаю видеть дублируемую логику в контроллерах, которые мне нужны для реорганизации.

С другой стороны, добавление авторизации к модели означает, что у меня должен быть некоторый способ получить текущего пользователя из модели, что кажется неправильным. В качестве альтернативы, я мог бы добавить параметр "current_user" для каждого метода модели, но это кажется еще хуже.

Итак, какова распространенная практика? Могу ли я поставить код авторизации в модель или сохранить ее в контроллере?

Ответ 1

Я думаю, что это серая область. Можно утверждать, что пользовательский доступ является частью сопоставления между миром HTTP и объектно-ориентированным миром. Это то, что контроллер предназначен для (следовательно, тяжелого использования статики), чтобы преобразовать входящий запрос, готовый обрабатывать бизнес-правила в модели домена.

Я бы предположил, что логика контроллера является абсолютно подходящим местом для контроля доступа к модели, тем более, что она управляется в основном на уровне аннотации, а аутентификация абстрагируется с классом безопасности.

Ответ 2

В большинстве случаев безопасность должна быть одним (или более) слоем над моделью. Безопасность - это домен, собственный, ограничивающий доступ к уровню более низкого уровня.

Я не думаю, что безопасность должна выполняться на уровне контроллера.

По-моему, это должно выглядеть так:

Вид → Контроллер → Безопасность → Модель

Уровень безопасности может быть фасадом или прокси-сервером по модели, защищая доступ, но быть прозрачным для контроллера.

Однако, если представления должны быть изменены в зависимости от прав доступа пользователя, некоторые проверки могут произойти на уровне контроллера (например, задание значения свойства BuEdit boolean на ViewModel).

Ответ 3

Мне лично очень нравится, как игра! Защищенный модуль обрабатывает это (пособие всегда полезно здесь). Если вы не возражаете использовать аннотацию @Before, это довольно безболезненно.

Ответ 4

Авторизация не должна быть частью контроллера или модели домена.

Вместо этого он должен находиться в сервисном слое.

Контроллер должен просто действовать как диспетчер и делегировать между HTTP и службой приложений. Это приложение, в котором происходит оркестровка. Это лучшее место для размещения авторизации.

Предположим, что пользователю A разрешен доступ к данным из домена X, но он не разрешен даже для доступа на чтение для данных из домена Y. Если авторизация помещается в контроллер, тогда пользователь A получает разрешение в контроллере X и через служебные вызовы могут получить доступ к данным из домена Y, что не является тем, что мы ожидали.

Так как модели домена взаимодействуют друг с другом на уровне обслуживания, поэтому лучше всего разместить авторизацию на одном уровне.

Ответ 5

Я нахожусь на этом этапе и намереваюсь справиться с этим следующим образом:

Нет проверки формы с помощью JS, вместо этого через HTTPS ajax
Класс Ajax php
Данные формы, отправленные модели в качестве ее данных для конкретной проверки для
общий тип, такой как адрес электронной почты и пароль (вероятная проверка массива-помощника будет повторно использоваться другими классами, поэтому это определенно область модели).
Если ошибка не найдена в таблице пользователя для электронной почты учетных данных /
учетные данные паролей, переданные контроллеру с помощью аутентификации
типа login/signup/password reset
контроллер затем создает требуемое представление вывода или устанавливает, что пользователь зарегистрирован в сеансе и т.д.

Это основано на Laravel, но у меня есть собственная библиотека, поскольку я хочу, чтобы она была независимой от laravel и просто была основана на этом жизненном требовании.

Дело в том, что модель ищет требуемые учетные данные в качестве данных, а затем отправляет контроллеру, так как ему все равно, как его обрабатывать. Я думаю, что это единственный способ сделать эту область окончательной ответственностью между каждым из компонентов.

Ответ 6

Из моего личного опыта с каркасами MVC я бы сказал:

Модель - это объект, представляющий таблицу базы данных, которая должна быть чистый и не должен содержать никакой дополнительной логики.
Контроллер - это место, где принимаются решения и другие пользовательская логика, поэтому авторизация должна быть в контроллере. Это может быть спроектирован какой-то крючок, который может проверить, разрешен ли пользователь или нет во всех необходимых местах, чтобы вы не имели повторения кода DRY.
Лучший способ дать разрешение пользователю, если вы используете типичный Архитектура REST состоит в том, чтобы сделать маркер, сохранить его в файле данных и на на стороне клиента и проверить этот токен при каждом запросе. Если вы используете приложение веб-браузера вы можете использовать серверные сеансы для авторизации ( Это намного проще).

Поэтому я предлагаю сохранить логику авторизации в контроллере.