Slik sikrer du en REST API med lumen

Lumen er Laravel's lillebror: et raskt, lett mikroramme for å skrive RESTful APIs. Med bare litt kode kan du bruke Lumen til å bygge en sikker og ekstremt rask RESTful API.

I denne videoopplæringen fra kurset mitt, Opprett en REST-API med lumen, lærer du hvordan du bruker Lumen's innebygde autentiserings-mellomvare for å sikre en REST-API med Lumen.

Videoen refererer til kode fra en prøvemusikkbutikk API som vi opprettet i tidligere leksjoner av kurset. Du kan se full kildekoden fra kurset på GitHub.

Slik sikrer du en REST API med lumen

 

Autentisering i Lumen

Sikkerhet er en svært viktig del, ikke bare av en web-API, men av et program. Og dessverre kan implementering av autentisering være en vanskelig ting. Men heldigvis er autentisering innebygd i Lumen, slik at alt vi trenger å gjøre er å aktivere autentisering og deretter skrive noen linjer med kode for å autentisere en bruker og deretter noen flere linjer med kode for å beskytte de tingene vi vil beskytte.

I vårt eksempel vil vi beskytte tre metoder på vår gitarkontroller. De er opprett, oppdater og slett metoder. Dette er ting som bare en godkjent bruker skal ha tilgang til. 

Så la oss starte med å gå til bootstrap-mappen og åpne app.php. 

Det er to uttalelser som vi trenger å ikke kommentere. Den første er anropet til routeMiddleware, som setter opp autentisering mellomvare. Vi ønsker også å registrere autorisasjonsleverandøren. Så den andre erklæringen er $ App-> registrere (App \ Providers \ AuthServiceProvider :: klasse);. Bare ved å uncommenting disse to uttalelsene, kan vi nå bruke autentisering i vår søknad.

Nå ønsker vi å legge merke til vår autentisering mellomvare. Så la oss gå til App \ Http \ Middleware \ Authenticate.php, og inne i denne klassen er det en metode som kalles håndtak, og denne metoden vil utføre før våre beskyttede metoder. 

Så når som helst vi gjør en forespørsel om å opprette, oppdatere eller slette metoder, vil autentiseringsmiddelvaren bli brukt, og dette håndtak Metoden kommer til å bli kalt.

Hvis brukeren ikke er autentisert, vil den returnere en 401. Ellers vil den sende forespørselen videre til den neste tingen som vil behandle den forespørselen. 

Så det er en ting vi trengte å se på. Den andre er inne i Leverandørmappen, og det er AuthServiceProvider.php.

Nå nederst i denne filen er en metode kalt støvel, og innsiden av oppstart er et anrop til dette viaRequest metode. Og dette er metoden som er ansvarlig for faktisk autentisering av brukeren. Så dette vil være avhengig av implementeringen vår. Og i denne leksjonen vil implementeringen vår bli veldig enkel.

Det vi skal gjøre, er å se etter en overskrift som heter Api-Token. Og hvis det er en viss verdi, så skal vi si at brukeren er autentisert. For å si at en bruker er autentisert, må vi returnere en brukerseksempel. Hvis vi returnerer null, betyr det at brukeren ikke er autentisert.

Så la oss gå videre og skriv den koden. Jeg skal kommentere denne eksisterende koden. Og det første vi skal gjøre er å hente Api-Token-overskriften. Så vi skal bruke vår forespørsel, vi skal ringe header-metoden, og vi vil ha Api-Token. 

$ header = $ request-> header ('Api-Token');

La meg først og fremst si at dette ikke er sikkert. Vi ville definitivt ønske å lagre våre brukere i en database. De bør hver ha sine egne unike tokens og egentlig skal vi jobbe med private og offentlige nøkler. Men jeg skal legge alle implementeringsdetaljer opp til deg. Det vi vil se er hvordan autentisering mellomvare plugger inn i søknaden vår slik at vi kan få det til å fungere, og da kan du implementere hva det er som du vil implementere.

Så vi skal hente toppteksten som heter Api-Token. Og la oss først og fremst sjekke for å se om vi har noe der. 

Nå er det eneste andre som vi trenger å gjøre, å si hvor vi vil bruke vår autentisering mellomvare. Vi kan gjøre det på en rekke steder.

Den første er når vi definerer våre ruter. For eksempel ønsker vi å beskytte vår postforespørsel. Så i stedet for å skrive vår rute som vi gjorde, kunne vi gjøre dette. Det er egentlig det samme, men det andre argumentet vi passerte til postmetoden, kommer til å ha to nøkler og verdier.

Så uten å gå lenger, kunne vi hoppe over til Fiddler, og vi kan gjøre en innleggsbeskjed, og vi kunne se om det ville bli beskyttet.

Nå er en av de store tingene om Fiddler at den holder styr på alle forespørsler vi har gjort. Så vi trenger bare å finne hvor vi gjorde en POST-forespørsel. Og hvis vi prøver å utføre dette, får vi en 401. Men hvis vi tar med denne Api-Token-heisen, og hvis vi setter det til "fugler fly south", så når vi gjør denne forespørselen, får vi 200, og vi vet allerede at dataene er nå i databasen.

Så det er det første alternativet. Men det andre alternativet er å spesifisere vår mellomvare inni konstruktørens kontrollør. Så la oss kommentere koden vi nettopp skrev og i stedet bruke vår gamle rute. 

La oss gå til vår gitarkontroller og legge til følgende kode:

Så hvis vi går tilbake til Fiddler, og hvis vi utsteder samme forespørsel, la oss bare endre verdien til et lag og lage til Fender-så skal vi se at det fortsatt fungerer. Så når vi utfører denne forespørselen, får vi en 200. Hvis vi tar ut Api-Token, får vi en 401. 

La oss også gi ut noen av de andre forespørslene. Så la oss gjøre en GET-forespørsel slik at vi kan hente de gitarene og få deres IDer. La oss bli kvitt Api-Token bare slik at vi kan se at dette fungerer uten noen form for godkjenning. Og vi får ID på 1 og ID på 2. 

Så hvis vi går tilbake til komponisten, la oss lage en PUT-forespørsel til gitaren med ID på 2.

For dataene som vi skal sende, kommer merket til å være Fender, men la oss endre modellen fra et strat til en telecaster. Nå uten Api-Token, bør dette ikke fungere. Så når vi kjører, får vi en 401. Men la oss legge til Api-Token og deretter verdien, fuglene flyr sørover, og den forespørselen kommer tilbake 200. 

Så bare for fullstendig skyld, la oss gjøre en DELETE forespørsel. La oss slette gitaren med en ID på 1. Vi burde få 200, og en la oss gjenta forespørselen for å hente alle gitarene våre. Og vi skal bare ha en, og den skal ha en ID på 2. Merket er Fender, og modellen er telecaster. 

Så legge til godkjenning til en Lumen-applikasjon er veldig, veldig enkelt. Annet enn å legge til mellomvare, er hoveddelen av koden du må skrive, inne i AuthServiceProvider klasse. Du må skrive koden som er ansvarlig for å autentisere brukeren, men når det er gjort, har du en sikker API.

Se hele kurset

I hele kurset, Opprett en REST API med Lumen, vil jeg vise deg hvordan du kommer i gang med å bygge REST APIer med Lumen-rammen. Du starter med å etablere et Lumen-utviklingsmiljø og fortsetter å bygge en komplett API for en musikkbutikk, inkludert ruting, MySQL-databasekobling og sikkerhet.