Laravel: Разница между маршрутом Middleware и политикой

Question

Я разрабатываю приложение с laravel, я понял, что то, что можно сделать с Policy, можно сделать с помощью Middleware. Скажем, я хочу, чтобы пользователь не обновлял маршрут, если он/она не является владельцем этой информации, я могу легко проверить маршрут и сделать то же самое из политики.

Так что мой вопрос, почему я должен использовать policy над промежуточным слоем и наоборот

Answer 1

Маршрут промежуточного слой позволяет применять обработку запросов к большому диапазону маршрутов, вместо того чтобы повторять код в каждом действии контроллера - проверку подлинности и перенаправлять гостей - хороший пример. Контроллеры вместо этого содержат логику, уникальную для определенных маршрутов/действий - для этого вы можете использовать промежуточное ПО, но для каждого маршрута вам потребуется отдельное промежуточное ПО, и все это будет очень грязно.

Политики/возможности - это просто способ проверки прав пользователя - вы можете запросить их у контроллера или из промежуточного программного обеспечения или в другом месте. Они возвращают true или false, поэтому они не эквивалентны контроллерам или промежуточному программному обеспечению. В большинстве случаев возможности будут сравнивать пользователя с другой моделью, которая будет загружена на основе идентификатора, отправленного на действие контроллера, но, вероятно, есть некоторые приложения для использования с промежуточным программным обеспечением.

Answer 2

В настоящее время я просматриваю небольшой рефакторинг с моими ролями, разрешениями и маршрутами и задаю себе тот же вопрос.

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

Для справки вот Laravel документы ...

Middleware «Могу ли я увидеть это? Могу ли я ехать сюда?»

HTTP-промежуточное программное обеспечение обеспечивает удобный механизм фильтрации HTTP запросов, поступающих в ваше приложение. Например, Laravel включает в себя связующее ПО , которое проверяет пользователя вашего приложения: аутентифицировано. Если пользователь не аутентифицирован, промежуточное программное обеспечение будет перенаправить пользователя на экран входа в систему. Однако, если пользователь аутентифицирован, промежуточное программное обеспечение позволит продолжить запрос в приложение.

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

https://laravel.com/docs/master/middleware#introduction

В моем чтении, Middleware о работе на уровне запроса. В терминах «Может ли этот пользователь посмотреть на странице?» Или «Может ли этот пользователь что-то здесь сделать?»

Если это так, то идет метод контроллера, связанный с этой страницей. Интересно, что Middleware может сказать: «Да, вы можете пойти туда, но я напишу, что вы собираетесь». И т.п.

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

Политики «Могу ли я это сделать? Могу ли я это изменить?»

В дополнение к предоставлению услуг аутентификации из коробки, Laravel также предоставляет простой способ организовать логику авторизации и управления доступом к ресурсам. Существует множество методов и помощников , которые помогут вам в организации вашей логики авторизации, и мы рассмотрим каждый из них в этом документе. Однако

https://laravel.com/docs/master/authorization#introduction

политика, как представляется, более озабочены делать. Может ли пользователь обновить любую запись или только их?

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

Как tjbb mentioned, промежуточное ПО может сделать маршруты очень грязными и трудными в управлении. Это пример из моего файла маршрутов:

Проблема

Route::group(['middleware' =>'role:person_type,person_type2',], function() { 
     Route::get('download-thing/{thing}', [ 
      'as' => 'download-thing', 
      'uses' => 'ThingController@download' 
     ]); 
    }); 

Это становится очень трудно читать в моем файле маршрута!

Другого подход с политикой

//ThingController 
public function download(Thing $thing) 
{ 
    //Policy method and controller method match, no need to name it 
    $this->authorize($thing); 

    //download logic here.... 
}