Poorten en beleid in Laravel

Vandaag gaan we het autorisatiesysteem van het Laravel-webraamwerk bespreken. Het Laravel-raamwerk implementeert autorisatie in de vorm van poorten en beleid. Na een inleiding tot poorten en beleid, zal ik de concepten demonstreren door een aangepast voorbeeld te implementeren.

Ik neem aan dat u zich al bewust bent van het ingebouwde Laravel-authenticatiesysteem, dat is iets dat essentieel is om het concept van autorisatie te begrijpen. Vanzelfsprekend werkt het autorisatiesysteem samen met het authenticatiesysteem om de legitieme gebruikerssessie te identificeren.

Als u niet op de hoogte bent van het Laravel-authenticatiesysteem, raad ik u aan de officiële documentatie door te nemen, die u praktische uitleg geeft over het onderwerp.

Laravel's benadering van autorisatie

Inmiddels zou u al moeten weten dat het Laravel-autorisatiesysteem bestaat uit twee smaken: poorten en beleid. Hoewel het klinkt als een gecompliceerde aangelegenheid, zou ik zeggen dat het vrij eenvoudig is om het te implementeren als je het eenmaal onder de knie hebt!

Met poorten kunt u een autorisatieregel definiëren met behulp van een eenvoudige op afsluiting gebaseerde aanpak. Met andere woorden, als u een actie wilt autoriseren die niet gerelateerd is aan een specifiek model, is de poort de perfecte plaats om die logica te implementeren.

Laten we even kijken hoe gate-gebaseerde autorisatie er uitziet:

... Gate :: define ('update-post', functie ($ user, $ post) return $ user-> id == $ post-> user_id;); ... 

Het bovenstaande fragment definieert de autorisatieregel -update-bericht die u overal in uw toepassing kunt bellen.

Aan de andere kant moet u beleid gebruiken wanneer u de autorisatielogica van een willekeurig model wilt groeperen. Laten we bijvoorbeeld zeggen dat u een berichtmodel in uw toepassing hebt en dat u de CRUD-acties van dat model wilt autoriseren. In dat geval is het beleid dat u moet implementeren.

class PostPolicy openbare functie-weergave (gebruiker $ gebruiker, bericht $ post)  openbare functie maken (gebruiker $ gebruiker)  openbare functie-update (gebruiker $ gebruiker, bericht $ bericht)  openbare functie verwijderen (gebruiker $ gebruiker, bericht $ bericht) 

Zoals u ziet, is het een vrij eenvoudige beleidsklasse die de autorisatie voor de CRUD-acties van de Post model-.

Dus dat was een inleiding tot poorten en beleid in Laravel. Vanaf het volgende deel zullen we een praktische demonstratie van elk element doornemen.

Gates

In dit gedeelte zien we een voorbeeld uit de praktijk om het begrip poorten te begrijpen.

Vaker wel dan niet, kijkt u naar de Laravel-serviceprovider wanneer u een onderdeel of een dienst moet registreren. Naar aanleiding van die conventie, laten we doorgaan en onze aangepaste poort definiëren in de app / Providers / AuthServiceProvider.php zoals getoond in het volgende fragment.

 'App \ Policies \ ModelPolicy',]; / ** * Verificatie- / autorisatiediensten registreren. * * @return void * / public function boot () $ this-> registerPolicies (); Gate :: define ('update-post', functie ($ user, $ post) return $ user-> id == $ post-> user_id;); 

In de bagageruimte methode, hebben we onze aangepaste poort gedefinieerd:

Gate :: define ('update-post', functie ($ user, $ post) return $ user-> id == $ post-> user_id;);

Bij het definiëren van een poort is er een afsluiting vereist die WAAR of ONWAAR retourneert op basis van de autorisatielogica die is gedefinieerd in de poortdefinitie. Afgezien van de sluitingsfunctie, zijn er andere manieren om poorten te definiëren.

De volgende poortdefinitie roept bijvoorbeeld de controlleractie aan in plaats van de sluitingsfunctie.

Gate :: define ('update-post', 'ControllerName @ MethodName');

Laten we nu een aangepaste route toevoegen, zodat we een demonstratie kunnen maken van hoe poortgebaseerde autorisatie werkt. In het routesbestand routes / web.php, laten we de volgende route toevoegen.

Route :: get ('service / post / gate', 'PostController @ gate');

Laten we een bijbehorend controllerbestand maken app / Http / Controllers / PostController.php ook.

In de meeste gevallen gebruik je de toestaat of ontkent methode van de Poort gevel om een ​​bepaalde actie te autoriseren. In ons voorbeeld hierboven hebben we de toestaat methode om te controleren of de huidige gebruiker in staat is om de -update-bericht actie.

Gebruikers met scherpe ogen zouden gemerkt hebben dat we alleen het tweede argument hebben aangenomen $ bericht tot de sluiting. Het eerste argument, de huidige ingelogde gebruiker, wordt automatisch geïnjecteerd door de Poort facade.

Dus dat is hoe je poorten zou moeten gebruiken om acties in je Laravel-applicatie goed te keuren. Het volgende gedeelte gaat over het gebruik van beleid, als u autorisatie voor uw modellen wilt implementeren.

beleid

Zoals we eerder hebben besproken, wanneer u uw autorisatieacties voor een bepaald model of resource logisch wilt groeperen, is dit het beleid waarnaar u op zoek bent.

In deze sectie maken we een beleid voor het Post-model dat zal worden gebruikt om alle CRUD-acties te autoriseren. Ik neem aan dat u het Post-model al in uw toepassing hebt geïmplementeerd; anders zal iets soortgelijks doen.

De Laravel ambachtsman opdracht is je beste vriend als het gaat om het maken van gedrukte code. U kunt de volgende artisan-opdracht gebruiken om een ​​beleid voor het berichtmodel te maken.

$ php artisan make: policy PostPolicy --model = Plaatsen

Zoals u kunt zien, hebben we de --model = Bericht argument zodat alle CRUD-methoden worden gemaakt. Als dat niet het geval is, wordt er een lege beleidsklasse gemaakt. U kunt de zojuist gemaakte beleidsklasse vinden op app / Beleid / PostPolicy.php.

Laten we het vervangen door de volgende code.

id> 0;  / ** * Bepaal of de gebruiker het bericht kan bijwerken. * * @param \ App \ Gebruiker $ gebruiker * @param \ App \ Bericht $ post * @return gemengd * / publieke functie update (Gebruiker $ gebruiker, Bericht $ bericht) retour $ gebruiker-> id == $ post-> gebruikersnaam;  / ** * Bepaal of de gebruiker het bericht kan verwijderen. * * @param \ App \ Gebruiker $ gebruiker * @param \ App \ Bericht $ bericht * @ retour gemengd * / openbare functie verwijderen (Gebruiker $ gebruiker, Bericht $ bericht) terug $ gebruiker-> id == $ bericht-> gebruikersnaam; 

Om onze Policy-klasse te kunnen gebruiken, moeten we deze registreren via de Laravel-serviceprovider, zoals in het volgende fragment wordt getoond.

 'App \ Policies \ ModelPolicy', Post :: class => PostPolicy :: class]; / ** * Verificatie- / autorisatiediensten registreren. * * @return void * / public function boot () $ this-> registerPolicies (); 

We hebben het in kaart brengen van ons beleid toegevoegd in de $ beleid eigendom. Het geeft Laravel de opdracht om de corresponderende beleidsmethode te gebruiken om de CRUD-actie te autoriseren.

U moet ook het beleid registreren met behulp van de registerPolicies methode, zoals we hebben gedaan in de bagageruimte methode.

Als we verder gaan, maken we een paar aangepaste routes in de routes / web.php bestand zodat we onze beleidsmethoden daar kunnen testen.

Route :: get ('service / post / weergave', 'PostController @ view'); Route :: get ('service / post / create', 'PostController @ create'); Route :: get ('service / post / update', 'PostController @ update'); Route :: get ('service / post / verwijderen', 'PostController @ delete');

Laten we ten slotte een bijbehorende controller maken op app / Http / Controllers / PostController.php.

can ('view', $ post)) echo "De huidige aangemelde gebruiker kan de post bijwerken: $ post-> id";  else echo 'Not Authorized.';  public function create () // krijg huidige ingelogde gebruiker $ user = Auth :: user (); if ($ user-> can ('create', Post :: class)) echo 'Huidige ingelogde gebruiker mag nieuwe posts maken.';  else echo 'Not Authorized';  Uitgang;  openbare functie-update () // de huidige aangemelde gebruiker $ user = Auth :: user (); // load post $ post = Post :: find (1); if ($ user-> can ('update', $ post)) echo "De huidige aangemelde gebruiker kan de post bijwerken: $ post-> id";  else echo 'Not Authorized.';  public function delete () // krijg huidige ingelogde gebruiker $ user = Auth :: user (); // load post $ post = Post :: find (1); if ($ user-> can ('delete', $ post)) echo "De huidige aangemelde gebruiker kan de post verwijderen: $ post-> id";  else echo 'Not Authorized.'; 

Er zijn verschillende manieren waarop u uw acties kunt autoriseren met behulp van beleid. In ons voorbeeld hierboven hebben we de Gebruiker model om ons te autoriseren Post modelacties.

Het gebruikersmodel biedt twee bruikbare methoden voor autorisatiedoeleinden-kan en kantelen. De kan methode wordt gebruikt om te controleren of de huidige gebruiker een bepaalde actie kan uitvoeren. En de tegenhanger van de kan methode, de kantelen methode, wordt gebruikt om het onvermogen van de uitvoering van de actie te bepalen.

Laten we het fragment van de pakken uitzicht methode van de controller om te zien wat het precies doet.

openbare functie weergave () // krijg huidige ingelogde gebruiker $ user = Auth :: user (); // load post $ post = Post :: find (1); if ($ user-> can ('view', $ post)) echo "De huidige aangemelde gebruiker kan de post bijwerken: $ post-> id";  else echo 'Not Authorized.'; 

Allereerst laden we de momenteel ingelogde gebruiker, die ons het object van het gebruikersmodel geeft. Vervolgens laden we een voorbeeldbericht met het berichtmodel.

Vooruitlopend hebben we de kan methode van het gebruikersmodel om de uitzicht actie van de Post model. Het eerste argument van de kan methode is de actienaam die u wilt autoriseren en het tweede argument is het modelobject waarvoor u een machtiging wilt ontvangen.

Dat was een demonstratie van hoe het te gebruiken Gebruiker model om de acties met behulp van beleid te autoriseren. Als alternatief kunt u de Controller Helper ook als u zich in de controller bevindt terwijl u een bepaalde actie autoriseert.

... $ this-> authorize ('view', $ post); ... 

Zoals u kunt zien, hoeft u het gebruikersmodel niet te laden als u de controllerhelper gebruikt.

Dus dat was het concept van beleid tot uw beschikking, en het is echt handig tijdens het autoriseren van een model of een bron, omdat het u toestaat om de autorisatielogica op één plek te groeperen.

Zorg er wel voor dat u helemaal geen poorten en beleid gebruikt voor dezelfde acties van het Model, anders creëert u problemen. Dat is het van mijn kant voor vandaag, en ik zal het een dag noemen!

Conclusie

Vandaag was het Laravel-autorisatie die centraal stond in mijn artikel. Aan het begin van het artikel introduceerde ik de belangrijkste elementen van Laravel-autorisatie, -poorten en -beleid.

Daarna hebben we onze aangepaste poort en beleid gemaakt om te zien hoe het werkt in de echte wereld. Ik hoop dat je het artikel leuk vond en iets nuttigs hebt geleerd in de context van Laravel.

Voor degenen onder u die net zijn begonnen met Laravel of die op zoek zijn om uw kennis, site of applicatie uit te breiden met uitbreidingen, hebben wij een aantal dingen die u kunt bestuderen op Envato Market.

Zoals altijd zou ik graag van u horen in de vorm van opmerkingen met behulp van de onderstaande feed!