Laravel: Differenza tra percorso middleware e politica

Question

Sto sviluppando un'applicazione con laravel, mi sono reso conto che ciò che può essere fatto con Policy può essere fatto esattamente con Middleware. Diciamo che voglio impedire a un utente di aggiornare un percorso se lui/lei non è il proprietario delle informazioni, posso facilmente controllare dal percorso e posso fare lo stesso dalla politica.

Quindi la mia domanda è: perché dovrei usare policy su middleware e viceversa

Answer 1

middleware percorso consente di applicare richiesta la gestione di una vasta gamma di itinerari, invece di ripetere il codice in ogni azione di controllo - il controllo di autenticazione e reindirizzare gli ospiti è un buon esempio. I controller contengono invece una logica unica per rotte/azioni specifiche: è possibile utilizzare il middleware per questo, ma occorrerebbe un middleware separato per la logica di ogni route e tutto diventerebbe molto complicato.

Politiche/abilità sono semplicemente un modo di controllare le autorizzazioni dell'utente - è possibile interrogarle da un controller, o dal middleware o da qualsiasi altra parte. Restituiscono solo true o false, quindi non sono equivalenti a controller o middleware. La maggior parte delle volte le abilità confronteranno un utente con un altro modello, che sarà stato caricato in base a un identificatore inviato a un'azione del controller, ma probabilmente ci sono anche alcune applicazioni da utilizzare con il middleware.

Answer 2

Attualmente sto passando attraverso un piccolo refactoring con i miei ruoli, permessi e percorsi e mi sono posto la stessa domanda.

A livello di superficie, sembra che il middleware e le politiche realizzino la stessa idea generale. Controlla se un utente può fare quello che sta facendo.

Per riferimento qui è la documentazione laravel ...

Middleware "Posso vedere questo? Posso andare qui?"

Il middleware HTTP fornisce un comodo meccanismo per filtrare le richieste HTTP immettendo l'applicazione. Ad esempio, Laravel include un middleware che verifica che l'utente dell'applicazione sia autenticato. Se l'utente non è autenticato, il middleware sarà reindirizzare l'utente alla schermata di accesso. Tuttavia, se l'utente è autenticato , il middleware consentirà alla richiesta di procedere all'interno dell'applicazione.

Ovviamente, è possibile scrivere middleware aggiuntivo per eseguire una varietà di attività oltre all'autenticazione. Un middleware CORS potrebbe essere il responsabile dell'aggiunta delle intestazioni corrette a tutte le risposte lasciando la tua applicazione . Un middleware di registrazione potrebbe registrare tutte le richieste in entrata nella tua applicazione.

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

Nella mia lettura, Middleware è di circa operante al livello richiesta. In termini di "Può questo utente vedere una pagina?" O "Questo utente può fare qualcosa qui?"

In tal caso, passa al metodo del controller associato a tale pagina. Abbastanza interessante, il middleware potrebbe dire: "Sì, puoi andare lì, ma ti scriverò che stai andando". Eccetera.

Una volta terminato. Non ha più controllo o voce in ciò che l'utente sta facendo. Un altro modo in cui lo considero il mediatore.

Politiche "Posso fare questo? Posso cambiare questo?"

Oltre a fornire servizi di autenticazione, fuori dalla scatola, laravel fornisce anche un modo semplice per organizzare la logica di autorizzazione e controllare l'accesso alle risorse. Esistono vari metodi e gli helper per assistervi nell'organizzazione della vostra logica di autorizzazione, e copriremo ognuno di essi in questo documento.

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

Politiche tuttavia, sembrano essere più interessati a fare . L'utente può aggiornare qualsiasi voce, o solo la loro?

Queste domande sembrano adeguate per un metodo di controllo in cui sono organizzati tutti gli inviti all'azione su una risorsa. Recupera questo oggetto, memorizza o aggiorna l'articolo.

Come tjbb mentioned, il middleware può rendere i percorsi molto complicati e difficili da gestire. Questo è un esempio dal mio file rotte:

Il problema

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

Questo diventa molto difficile da leggere nel mio file percorso!

Un altro approccio con le politiche

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

    //download logic here.... 
}