Share
Lumen is Laravel's kleine broertje: een snel, lichtgewicht micro-framework voor het schrijven van RESTful API's. Met slechts een klein beetje code, kunt u Lumen gebruiken om een veilige en extreem snelle RESTful API te bouwen.
In deze video-zelfstudie van mijn cursus Create a REST API with Lumen leer je hoe je de ingebouwde authenticatie-middleware van Lumen kunt gebruiken om een REST API met Lumen te beveiligen.
De video verwijst naar code uit een voorbeeld van een muziekwinkel-API die we in eerdere lessen van de cursus hebben gemaakt. Je kunt de volledige broncode van de cursus bekijken op GitHub.
Beveiliging is een zeer belangrijk onderdeel, niet alleen van een web-API, maar van een toepassing. En helaas kan het implementeren van authenticatie een moeilijk ding zijn. Maar gelukkig is authenticatie ingebouwd in Lumen, dus alles wat we moeten doen is authenticatie inschakelen en dan een paar regels code schrijven om een gebruiker te authenticeren en dan nog een paar regels code om de dingen te beschermen die we willen beschermen.
In ons voorbeeld willen we drie methoden beschermen op onze gitaarcontroller. Dit zijn de methoden voor maken, bijwerken en verwijderen. Dit zijn dingen waar alleen een geverifieerde gebruiker toegang toe zou moeten hebben.
Dus laten we beginnen door naar de bootstrap-map te gaan en app.php te openen.
Er zijn twee verklaringen die we moeten verwijderen. De eerste is de oproep aan routeMiddleware, waarmee de authenticatie-middleware wordt ingesteld. We willen ook de auth-serviceprovider registreren. Dus de tweede verklaring is $ App-> registreren (App \ Providers \ AuthServiceProvider :: Klasse);. Alleen al door deze twee opmerkingen niet te controleren, kunnen we nu authenticatie gebruiken in onze applicatie.
Nu willen we kennis maken met onze authenticatie-middleware. Dus laten we gaan App \ Http \ Middleware \ Authenticate.php, en binnen deze klasse is er een methode genaamd handvat, en deze methode wordt uitgevoerd vóór onze beschermde methoden.
Dus elke keer dat we een verzoek indienen voor onze methoden voor maken, bijwerken of verwijderen, wordt de authenticatie-middleware gebruikt, en dit handvat methode wordt gebeld.
Als de gebruiker niet is geverifieerd, retourneert deze een 401. Anders wordt de aanvraag doorgegeven aan het volgende dat deze aanvraag verwerkt.
Dus dat is iets waar we naar moesten kijken. De andere bevindt zich in de map Providers en het is AuthServiceProvider.php.
Nu aan de onderkant van dit bestand wordt een methode genoemd bagageruimte, en binnenkant van boot is een oproep hiervoor viaRequest methode. En dit is de methode die verantwoordelijk is voor het daadwerkelijk verifiëren van de gebruiker. Dit gaat dus afhankelijk zijn van onze implementatie. En in deze les zal onze implementatie heel eenvoudig zijn.
Wat we gaan doen is controleren op een header genaamd Api-Token. En als het een bepaalde waarde is, gaan we zeggen dat de gebruiker is geverifieerd. Om te kunnen zeggen dat een gebruiker is geverifieerd, moeten we een gebruikersexemplaar retourneren. Als we null retourneren, betekent dit dat de gebruiker niet is geverifieerd.
Dus laten we doorgaan en die code schrijven. Ik ga deze bestaande code becommentariëren. En het eerste dat we gaan doen, is de Api-Token-header ophalen. Dus we gaan ons verzoek gebruiken, we zullen de header-methode noemen en we willen Api-Token.
Accentsconagua
$ header = $ request-> header ('Api-Token');Laat ik om te beginnen zeggen dat dit niet veilig is. We zouden onze gebruikers zeker in een database willen opslaan. Ze zouden elk hun eigen unieke tokens moeten hebben en eigenlijk zouden we moeten werken met private en publieke sleutels. Maar ik laat alle details over de implementatie aan u over. Wat we willen zien, is hoe de authenticatie-middleware wordt aangesloten op onze applicatie, zodat we die kunnen krijgen, en dan kunt u implementeren wat u wilt implementeren.
Dus we gaan de header genaamd Api-Token ophalen. En laten we eerst controleren of we daar iets hebben.
Nu, het enige andere wat we moeten doen is zeggen waar we onze authenticatie-middleware willen gebruiken. We kunnen dat op verschillende plaatsen doen.
De eerste is wanneer we onze routes definiëren. We willen bijvoorbeeld ons postverzoek beschermen. Dus in plaats van onze route te schrijven zoals we deden, konden we dit doen. Het is in essentie hetzelfde, maar het tweede argument dat we hebben doorgegeven aan de postmethode heeft twee sleutels en waarden.
Dus zonder verder te gaan, kunnen we naar Fiddler gaan en kunnen we een verzoek indienen en we kunnen zien of dat beschermd zou zijn.
Nu is een van de geweldige dingen over Fiddler dat het alle verzoeken bewaart die we hebben gemaakt. We moeten dus alleen vinden waar we een POST-aanvraag hebben gedaan. En als we dit proberen uit te voeren, krijgen we een 401. Maar als we die Api-Token-koptekst opnemen, en als we dat instellen op "vogels naar het zuiden vliegen", dan krijgen we telkens wanneer we dit doen een 200, en we weten al dat die gegevens nu in de database staan.
Dus dat is de eerste optie. Maar de tweede optie is om onze middleware binnen in de constructor van onze controller te specificeren. Dus laten we de code die we zojuist hebben geschreven toelichten en in plaats daarvan onze oude route gebruiken.
Laten we naar onze gitaarcontroller gaan en de volgende code toevoegen:
Dus als we teruggaan naar Fiddler en als we datzelfde verzoek uitbrengen - laten we gewoon de waarde veranderen in een strat en het merk in Fender - dan zullen we zien dat het nog steeds werkt. Dus als we dat verzoek uitvoeren, krijgen we een 200. Als we de Api-Token verwijderen, krijgen we een 401.
Laten we nu ook enkele van de andere verzoeken indienen. Dus laten we een GET-verzoek doen zodat we die gitaren kunnen ophalen en hun ID's kunnen krijgen. Laten we de Api-Token verwijderen zodat we kunnen zien dat dit werkt zonder enige vorm van authenticatie. En we krijgen ID van 1 en ID van 2.
Dus als we teruggaan naar de componist, laten we dan een PUT-verzoek doen voor de gitaar met ID van 2.
Voor de gegevens die we gaan verzenden, is het merk Fender, maar laten we het model veranderen van een strat in een telecaster. Zonder de Api-Token zou dit niet moeten werken. Dus wanneer we uitvoeren, krijgen we een 401. Maar laten we het Api-token toevoegen en dan de waarde, vogels vliegen naar het zuiden en dat verzoek gaat terug 200.
Laten we dus voor de volledigheid een VERWIJDEREN-verzoek doen. Laten we de gitaar verwijderen met een ID van 1. We zouden 200 moeten krijgen, en een laten we opnieuw het verzoek uitbrengen om al onze gitaren op te halen. En we zouden er maar één moeten hebben, en het zou een ID van 2 moeten hebben. Het merk is Fender en het model is telecaster.
Dus het toevoegen van authenticatie aan een Lumen-applicatie is heel, heel eenvoudig. Anders dan het toevoegen van de middleware, bevindt het grootste deel van de code die u moet schrijven zich in de AuthServiceProvider klasse. U moet de code schrijven die verantwoordelijk is voor de authenticatie van de gebruiker, maar zodra dat is gebeurd, beschikt u over een veilige API.
In de volledige cursus Create a REST API with Lumen, laat ik u zien hoe u aan de slag kunt met het bouwen van REST API's met het Lumen-framework. U begint met het opzetten van een Lumen-ontwikkelomgeving en bouwt een complete API voor een muziekwinkel op, inclusief routing, MySQL-databaseconnectiviteit en beveiliging.
