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

Я пишу веб-приложение с некоторыми требованиями 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 состоит в том, чтобы сделать маркер, сохранить его в файле данных и на на стороне клиента и проверить этот токен при каждом запросе. Если вы используете приложение веб-браузера вы можете использовать серверные сеансы для авторизации ( Это намного проще).

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