Подтвердить что ты не робот

Laravel: разница между промежуточным ПО и политикой маршрута

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

Итак, мой вопрос в том, почему я должен использовать Policy поверх промежуточного программного обеспечения и наоборот

4b9b3361

Ответ 1

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

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

Ответ 2

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

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

Для справки здесь laravel docs...

Middleware "Могу я увидеть это? Могу ли я пойти сюда?"

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

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

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

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

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

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

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

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

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

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

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

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

Проблема

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

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

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

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

    //download logic here....
}