Куда мы должны поместить код авторизации? FormRequest, Политики, контроллер, промежуточное ПРОГРАММНОЕ обеспечение …?

#laravel #authorization

#laravel #авторизация

Вопрос:

Где должен быть код авторизации в Laravel? У нас есть много опций и много плагинов для управления этой ситуацией, но я не совсем уверен, куда я должен поместить всю логику. Давайте посмотрим:

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

Представьте, что у нас есть приложение службы поддержки, выполненное в vuejs и Laravel в качестве API, поэтому у нас есть пользователи, группы, роли, разрешения. И, возможно, пользователь сможет видеть только свои билеты.

  1. Должны ли мы выполнить TicketPolicy с методами просмотра, обновления, создания? Может быть, нам следует использовать репозитории? Может быть, метод is_user_allowed в модели Ticket?
  2. Должны ли мы использовать промежуточное программное обеспечение в файлах маршрутов и делать что-то вроде Route::get(‘tickets /{ticket}’, ‘TicketsController @show’)-> промежуточное программное обеспечение (‘can: show’)? Или мы должны вызвать $this->authorize($ticket) в методах show, edit, update и store контроллера?
  3. Или, может быть, нам следует использовать метод FormRequest@authorize, а затем использовать что-то вроде $user->authorize(‘show’, $ ticket)?
  4. Что, если нам нужны группы или роли? Должны ли мы использовать какой-нибудь плагин, такой как Entrust и / или политики?

Как вы думаете, что вы делаете?

Комментарии:

1. все они хороши, это зависит от того, что именно вам нужно

Ответ №1:

Лучшее место, которое я нашел для размещения классов, группирующих конкретную логику, которая не вписывается в стандартный шаблон MVC, — это совершенно новая папка для Laravel. Я называю мои сервисы, вероятно, потому, что я где-то это прочитал. Одна из замечательных особенностей Laravel (и, вероятно, других современных фреймворков) — это гибкость, вы можете просто открыть папку, добавить новое пространство имен и содержать в нем все, что вам нужно.

Что касается вашего примера, я бы реализовал класс App Services Permissions, который содержал бы всю необходимую логику для доступа к различным ресурсам в вашем приложении. Затем вызывайте его методы везде, где они вам нужны, будь то Запросы, промежуточные программы или красноречивые модели.