Webes Kezelőfelület

JSON Web Token oktatóanyag: Példa a Laravel és az AngularJS szolgáltatásokra

Az egyoldalas alkalmazások, a mobilalkalmazások és a RESTful API-szolgáltatások növekvő népszerűségével webfejlesztők a back-end kód írása jelentősen megváltozott. Az olyan technológiákkal, mint az AngularJS és a BackboneJS, már nem sok időt töltünk a jelölések kiépítésével, ehelyett olyan API-kat építünk, amelyeket a front-end alkalmazásunk fogyaszt. Háttérünk inkább az üzleti logikáról és az adatokról szól, míg a prezentációs logika kizárólag a kezelőfelületre vagy a mobilalkalmazásokra kerül. Ezek a változások új módszerekhez vezettek a hitelesítés modern alkalmazásokban.

A hitelesítés minden webalkalmazás egyik legfontosabb része. Évtizedekig a sütik és a szerver-alapú hitelesítés volt a legegyszerűbb megoldás. A hitelesítés kezelése a modern mobil és egyoldalas alkalmazásokban azonban bonyolult lehet, és jobb megközelítést igényel. Az API-k hitelesítési problémáinak legismertebb megoldásai a OAuth 2.0 és a JSON web token (JWT).

Mielőtt belekezdenénk ebbe a JSON Web Token oktatóanyagba, mi is pontosan a JWT?

Mi az a JSON web token?

A JSON web-tokent olyan információk küldésére használják, amelyek ellenőrizhetők és megbízhatóak digitális aláírással. Kompakt és URL-ben biztonságos JSON objektumot tartalmaz, amelyet kriptográfia aláírással hitelesítenek annak hitelessége érdekében, és amely titkosítható is, ha a hasznos teher érzékeny információkat tartalmaz.

Kompakt felépítése miatt a JWT-t általában a HTTP Authorization -ban használják fejlécek vagy URL lekérdezési paraméterek.

A JSON web token felépítése

A JWT szekvenciája base64url kódolt értékek, amelyeket periódus karakterek választanak el egymástól.

JSON web token példa laravel és angularjs fájlokban

Itt van egy JWT token példa:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJpc3MiOiJ0b3B0YWwuY29tIiwiZXhwIjoxNDI2NDIwODAwLCJodHRwOi8vdG9wdGFsLmNvbS9qd3RfY2xhaW1zL2lzX2FkbWluIjp0cnVlLCJjb21wYW55IjoiVG9wdGFsIiwiYXdlc29tZSI6dHJ1ZX0. yRQYnWzskCZUxPwaQupWkiUzKELZ49eM7oWxAQK_ZXw

A fejléc tartalmazza a token metaadatait, és minimálisan tartalmazza az aláírás típusát és a titkosítási algoritmust. (Használhatja a JSON formázó eszköz a JSON objektum finomítására.)

Példa fejlécre

{ 'alg': 'HS256', 'typ': 'JWT' }

Ez a JWT példafejléc kijelenti, hogy a kódolt objektum JSON web Token, és hogy a HMAC SHA-256 algoritmus segítségével van aláírva.

Miután ez base64 kódolású, megvan a JWT első része.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Hasznos teher (követelések)

A JWT kontextusában a követelés meghatározható egy entitásról (általában a felhasználóról) szóló nyilatkozatként, valamint magának a tokennek a további metaadataként. A követelés tartalmazza azokat az információkat, amelyeket továbbítani szeretnénk, és amelyeket a szerver felhasználhat a JSON Web Token hitelesítés megfelelő kezeléséhez. Számos követelést tudunk nyújtani; ide tartoznak a bejegyzett igények, a nyilvános követelések és a magánjogi igények nevei.

Bejegyzett JWT követelések

Ezeket az igényeket regisztrálták a IANA JSON Web Token követelések nyilvántartás . Ezeknek a JWT-állításoknak nem célja a kötelező, inkább hasznos, interoperábilis állítások kiindulópontjának biztosítása.

Ezek tartalmazzák:

iss : A token kibocsátója
alatti : A token tárgya
hallom : A token közönsége
exp : A JWT lejárati ideje a Unix-időben meghatározott
nbf : „Nem előtte” idő, amely meghatározza azt az időpontot, amely előtt a JWT-t nem szabad elfogadni feldolgozásra
iat : „Kiadva” időpontban, Unix idő szerint, amikor a tokent kiadták
jti : A JWT ID igénylés egyedi azonosítót biztosít a JWT számára

Nyilvános követelések

A nyilvános követeléseknek ütközésálló neveket kell tartalmazniuk. Azáltal, hogy a név URI vagy URN, a névütközések elkerülhetők azoknál a JWT-knél, ahol a feladó és a vevő nem része egy zárt hálózatnak.

A nyilvános követelés nevére példa lehet: https://www.toptal.com/jwt_claims/is_admin, és a legjobb gyakorlat az, ha a követelést leíró fájlt helyez el ezen a helyen, hogy a dokumentációra hivatkozni lehessen.

Magánkövetelések

A magánjogi igények olyan helyeken használhatók, ahol a JWT-ket csak zárt környezetben cserélik ismert rendszerek között, például egy vállalkozáson belül. Ezek olyan állítások, amelyeket magunk határozhatunk meg, például felhasználói azonosítókat, felhasználói szerepeket vagy bármilyen más információt.

Olyan állításnevek használata, amelyek ellentmondásos szemantikai jelentéssel bírhatnak egy zárt vagy magánrendszeren kívül, ütközésnek vannak kitéve, ezért óvatosan használja őket.

Fontos megjegyezni, hogy a lehető legkisebb web-tokent szeretnénk megtartani, ezért csak a szükséges adatokat használjuk fel a nyilvános és a magánjogi igényekben.

JWT példa hasznos teher

{ 'iss': 'toptal.com', 'exp': 1426420800, 'https://www.toptal.com/jwt_claims/is_admin': true, 'company': 'ApeeScape', 'awesome': true }

Ennek a példának a hasznos teherének két bejegyzett követelése van, egy nyilvános és két magán követelés. Miután az base64 kódolásra került, megvan a JWT második része.

eyJpc3MiOiJ0b3B0YWwuY29tIiwiZXhwIjoxNDI2NDIwODAwLCJodHRwOi8vdG9wdGFsLmNvbS9qd3RfY2xhaW1zL2lzX2FkbWluIjp0cnVlLCJjb21wYW55IjoiVG9wdGFsIiwiYXdlc29tZSI6dHJ1ZX0

Aláírás

A JWT szabvány a JSON Web Signature (JWS) specifikációt követi az utolsó aláírt token előállításához. A kódolt JWT fejléc és a kódolt JWT hasznos terhelés kombinálásával jön létre, és egy erős titkosítási algoritmus, például HMAC SHA-256 segítségével aláírja. Az aláírás titkos kulcsát a szerver tartja, így képes lesz ellenőrizni a meglévő tokeneket és újakat aláírni.

$encodedContent = base64UrlEncode(header) + '.' + base64UrlEncode(payload); $signature = hashHmacSHA256($encodedContent);

Ez megadja nekünk a JWT utolsó részét.

yRQYnWzskCZUxPwaQupWkiUzKELZ49eM7oWxAQK_ZXw

JWT biztonság és titkosítás

Kritikus a TLS / SSL használata a JWT-vel együtt, hogy megakadályozzuk a ember közötti támadásokat. A legtöbb esetben ez elegendő lesz a JWT hasznos terhelésének titkosításához, ha az érzékeny információkat tartalmaz. Ha azonban további védelmi réteget akarunk hozzáadni, akkor a JWT hasznos terhelését is titkosíthatjuk JSON webes titkosítás (PLAY) specifikáció.

Természetesen, ha el akarjuk kerülni a JWE használatának további költségeit, akkor egy másik lehetőség az, hogy egyszerűen tároljuk az érzékeny információkat az adatbázisunkban, és a tokenünket további API-hívásokra használjuk a szerverhez, amikor csak bizalmas adatokhoz kell hozzáférnünk.

Miért van szükség web tokenekre?

Mielőtt meglátnánk a JWT-hitelesítés összes előnyét, meg kell vizsgálnunk a hitelesítés múltbeli módját.

Szerver alapú hitelesítés

Mivel a HTTP protokoll hontalan, létre kell hozni egy mechanizmust a felhasználói információk tárolására, valamint egy módot a felhasználó hitelesítésére minden későbbi bejelentkezés után. A legtöbb webhely sütiket használ a felhasználói munkamenet-azonosítók tárolásához.

Hogyan működik

A böngésző POST kérést küld a szervernek, amely tartalmazza a felhasználó azonosítóját és jelszavát. A szerver egy cookie-val válaszol, amelyet a felhasználó böngészőjében állítanak be, és munkamenet-azonosítót tartalmaz a felhasználó azonosítására.

Minden további kérés esetén a szervernek meg kell találnia azt a munkamenetet és deserializálnia kell, mert a felhasználói adatokat a szerveren tárolják.

A kiszolgáló alapú hitelesítés hátrányai

Nehezen méretezhető : A kiszolgálónak létre kell hoznia egy munkamenetet egy felhasználó számára, és azt fenn kell tartania valahol a szerveren. Ez történhet memóriában vagy adatbázisban. Ha elosztott rendszerünk van, meg kell győződnünk arról, hogy külön munkamenet-tárolót használunk, amely nincs összekapcsolva az alkalmazáskiszolgálóval.
Cross-origin kérelem megosztása (CORS) : Ha AJAX-hívásokat használunk egy erőforrás lekérésére egy másik tartományból („cross-origin”), akkor problémákat tapasztalhatunk a tiltott kérésekkel, mert alapértelmezés szerint a HTTP-kérelmek nem tartalmaznak cookie-kat a cross-origin kéréseknél.
Csatlakozás a webes keretrendszerhez : Szerver alapú hitelesítés használatakor a keretrendszerünk hitelesítési sémájához vagyunk kötve. Nagyon nehéz, sőt lehetetlen megosztani a munkamenet adatait a különböző webes keretek között, különböző programozási nyelveken írva.

Token alapú hitelesítés

A token alapú / JWT hitelesítés állapot nélküli, ezért nincs szükség felhasználói adatok tárolására a munkamenetben. Ez lehetővé teszi számunkra az alkalmazás méretezését anélkül, hogy aggódnánk, hová jelentkezett be a felhasználó. Ugyanazt a tokent használhatjuk biztonságos erőforrások lekérésére egy másik tartományból, mint ahová be vagyunk jelentkezve.

Hogyan működnek a JSON web Tokenek

A böngésző vagy a mobil kliens a felhasználói bejelentkezési információkat tartalmazó kérést intéz a hitelesítési kiszolgálóhoz. A hitelesítési szerver létrehoz egy új JWT hozzáférési tokent, és visszaadja azt az ügyfélnek. Minden korlátozott erőforrásra irányuló kérés esetén az ügyfél elküldi a hozzáférési jogkivonatot a lekérdezési karaktersorozatban vagy Authorization fejléc. Ezután a szerver ellenőrzi a tokent, és ha érvényes, akkor visszaküldi a biztonságos erőforrást az ügyfélnek.

A hitelesítési szerver bármilyen biztonságos aláírási módszerrel aláírhatja a tokent. Például egy szimmetrikus kulcs algoritmus, például a HMAC SHA-256 használható, ha van egy biztonságos csatorna a titkos kulcs megosztására az összes fél között. Alternatív megoldásként aszimmetrikus, nyilvános kulcsú rendszer, például az RSA is használható, kiküszöbölve a további kulcsmegosztás szükségességét.

A token alapú hitelesítés előnyei

Hontalan, könnyebben méretezhető : A token minden információt tartalmaz a felhasználó azonosításához, így nincs szükség a munkamenet állapotára. Ha terheléselosztót használunk, átadhatjuk a felhasználót bármely szervernek, ahelyett, hogy ugyanahhoz a kiszolgálóhoz lennénk kötve, ahová bejelentkeztünk.

Újrahasználhatóság : Sok különálló szerverünk lehet, amelyek több platformon és tartományon futnak, és ugyanazt a tokent használják fel újra a felhasználó hitelesítéséhez. Könnyű olyan alkalmazást létrehozni, amely megosztja az engedélyeket egy másik alkalmazással.

JWT Security : Mivel nem használunk sütiket, nem kell védekeznünk a webhelyek közötti kérelmek hamisítását (CSRF) érő támadások ellen. Ennek ellenére továbbra is titkosítanunk kell a tokenjeinket a JWE használatával, ha bármilyen érzékeny információt be kell raknunk beléjük, és a tokeninket HTTPS-en keresztül kell továbbítanunk, hogy megakadályozzuk a középen lévő támadásokat.

Teljesítmény : Nincs szerveroldali keresés a munkamenet megkeresésére és deserializálására minden egyes kérés esetén. Az egyetlen dolog, amit tennünk kell, a HMAC SHA-256 kiszámítása a token érvényesítéséhez és tartalmának elemzéséhez.

legjobb alkalmazások Android nugáthoz

JSON web-token példa Laravel 5 és AngularJS használatával

Ebben a JWT oktatóanyagban bemutatom, hogyan lehet megvalósítani az alapvető hitelesítést a JSON Web Tokenek használatával két népszerű webes technológiában: a Laravel 5 a háttérkódhoz és az AngularJS a frontend Single Page Application (SPA) példához. (Megtalálhatja a teljes bemutatót itt , és a forráskódot ez a GitHub-tár hogy kövesse az oktatóanyagot.)

Ez a JSON web token példa semmiféle titkosítást nem használ a követelésekben továbbított információk titkosságának biztosítására. A gyakorlatban ez gyakran rendben van, mert a TLS / SSL titkosítja a kérést. Ha azonban a token érzékeny információkat tartalmaz, például a felhasználó társadalombiztosítási számát, akkor azt a JWE használatával is titkosítani kell.

Laravel háttérprogram példa

A Laravel segítségével kezeljük a felhasználók regisztrációját, a felhasználói adatokat adatbázisba tároljuk és korlátozott adatokat szolgáltatunk, amelyek hitelesítésre szorulnak az Angular alkalmazás használatához. Létrehozunk egy példa API-domaint a kereszt-eredetű erőforrás-megosztás (CORS) szimulálására is.

Telepítés és projektindítás

A Laravel használatához telepítenünk kell a Zeneszerző csomagkezelő gépünkön. A Laravelben történő fejlesztéskor a Laravel Homestead előre csomagolt Vagrant dobozát használom. Teljes fejlesztői környezetet biztosít számunkra, az operációs rendszertől függetlenül.

A JWT Laravel alkalmazás indításának legegyszerűbb módja a Comparer Laravel Installer csomag használata.

composer global require 'laravel/installer=~1.1'

Most mindannyian készen állunk egy új Laravel projekt létrehozására a laravel new jwt futtatásával.

Ha bármilyen kérdése van ezzel a folyamattal kapcsolatban, kérjük, forduljon a hivatalos személyhez Laravel dokumentáció .

Miután létrehoztuk az alapvető Laravel 5 alkalmazást, be kell állítanunk a Homestead.yaml -t, amely konfigurálja a mappatérképezéseket és a tartományok konfigurációját a helyi környezetünkhöz.

Példa egy Homestead.yaml fájl:

--- ip: '192.168.10.10' memory: 2048 cpus: 1 authorize: /Users/ttkalec/.ssh/public.psk keys: - /Users/ttkalec/.ssh/private.ppk folders: - map: /coding/jwt to: /home/vagrant/coding/jwt sites: - map: jwt.dev to: /home/vagrant/coding/jwt/public - map: api.jwt.dev to: /home/vagrant/coding/jwt/public variables: - key: APP_ENV value: local

Miután elindítottuk Vagrant dobozunkat a vagrant up -val parancsot, és a vagrant ssh használatával beléptünk, navigálunk az előzőleg definiált projektkönyvtárba. A fenti példában ez /home/vagrant/coding/jwt lenne. Most már futhatunk php artisan migrate parancsot a szükséges felhasználói táblák létrehozásához az adatbázisunkban.

A zeneszerzői függőségek telepítése

Szerencsére van egy fejlesztői közösség, amely a Laravel-n dolgozik, és számos nagyszerű csomagot karbantart, amelyekkel újra felhasználhatjuk és kiterjeszthetjük alkalmazásunkat. Ebben a példában azt fogjuk használni tymon/jwt-auth , Sean Tymon, a tokenek kiszolgálói oldalán történő kezeléséért, és barryvdh/laravel-cors , a Barry vd. Heuvel, a CORS kezeléséhez.

jwt-auth

Igényelje a tymon/jwt-auth csomag a composer.json és frissítsük függőségeinket.

composer require tymon/jwt-auth 0.5.*

Adja hozzá a JWTAuthServiceProvider a mi app/config/app.php szolgáltatók tömb.

'TymonJWTAuthProvidersJWTAuthServiceProvider'

Ezután a app/config/app.php -ban fájl, a aliases alatt tömb, hozzáadjuk a JWTAuth homlokzat.

'JWTAuth' => 'TymonJWTAuthFacadesJWTAuth'

Végül szeretnénk közzétenni a config csomagot a következő paranccsal: php artisan config: publish tymon / jwt-auth

A JSON web tokenek titkos kulccsal vannak titkosítva. Ezt a kulcsot a php artisan jwt:generate segítségével generálhatjuk parancs. A config/jwt.php könyvtárunkba kerül fájl. A termelési környezetben azonban soha nem akarjuk, hogy a jelszavak vagy az API-kulcsok a konfigurációs fájlokban legyenek. Ehelyett a kiszolgáló környezeti változókba kell helyezni őket, és a env -val hivatkozniuk kell a konfigurációs fájlba funkció. Például:

'secret' => env('JWT_SECRET')

Tudhatunk meg többet erről a csomagról és annak összes konfigurációs beállításáról a Githubon .

laravel-cors

Igényelje a barryvdh/laravel-cors csomag a composer.json és frissítsük függőségeinket.

composer require barryvdh/laravel-cors [email protected]

Adja hozzá a CorsServiceProvider a mi app/config/app.php szolgáltatók tömb.

'BarryvdhCorsCorsServiceProvider'

Ezután adja hozzá a köztes szoftvert a app/Http/Kernel.php

'BarryvdhCorsMiddlewareHandleCors'

A konfiguráció közzététele egy helyi config/cors.php fájlt a php artisan vendor:publish parancs.

Példa egy cors.php fájlkonfiguráció:

return [ 'defaults' => [ 'supportsCredentials' => false, 'allowedOrigins' => [], 'allowedHeaders' => [], 'allowedMethods' => [], 'exposedHeaders' => [], 'maxAge' => 0, 'hosts' => [], ], 'paths' => [ 'v1/*' => [ 'allowedOrigins' => ['*'], 'allowedHeaders' => ['*'], 'allowedMethods' => ['*'], 'maxAge' => 3600, ], ], ];

HTTP-kérelmek továbbítása és kezelése

A rövidség kedvéért az összes kódomat beleteszem a route.php fájlba, amely felelős a Laravel útválasztásáért és a kérések delegálásáért a vezérlőkhöz. Általában dedikált vezérlőket hozunk létre az összes HTTP kérés kezelésére, és a kódunkat modulárisan és tisztán tartjuk.

Az AngularJS SPA nézetet a

Route::get('/', function () { return view('spa'); });

felhasználó regisztráció

Amikor egy POST -t készítünk kérés /signup felhasználónévvel és jelszóval megpróbálunk új felhasználót létrehozni és menteni az adatbázisba. A felhasználó létrehozása után létrejön egy JWT, amely JSON válasz útján kerül visszaadásra.

Route::post('/signup', function () { $credentials = Input::only('email', 'password'); try { $user = User::create($credentials); } catch (Exception $e) { return Response::json(['error' => 'User already exists.'], HttpResponse::HTTP_CONFLICT); } $token = JWTAuth::fromUser($user); return Response::json(compact('token')); });

Felhasználói bejelentkezés

Amikor egy POST -t készítünk kérés /signin felhasználónévvel és jelszóval ellenőrizzük, hogy a felhasználó létezik-e, és a JSON válaszon keresztül visszaad-e egy JWT-t.

Route::post('/signin', function () { $credentials = Input::only('email', 'password'); if ( ! $token = JWTAuth::attempt($credentials)) { return Response::json(false, HttpResponse::HTTP_UNAUTHORIZED); } return Response::json(compact('token')); });

Korlátozott erőforrás lekérése ugyanarról a tartományról

Miután a felhasználó be van jelentkezve, lekérhetjük a korlátozott erőforrást. Létrehoztam egy útvonalat /restricted amely egy erőforrást szimulál, amelyhez hitelesített felhasználóra van szükség. Ennek érdekében a Authorization a fejlécnek vagy a lekérdezési karaktersorozatnak meg kell adnia a JWT-t a háttérprogram ellenőrzéséhez.

Route::get('/restricted', [ 'before' => 'jwt-auth', function () { $token = JWTAuth::getToken(); $user = JWTAuth::toUser($token); return Response::json([ 'data' => [ 'email' => $user->email, 'registered_at' => $user->created_at->toDateTimeString() ] ]); } ]);

Ebben a példában a jwt-auth -t használom köztes szoftver a jwt-auth csomag a 'before' => 'jwt-auth' használatával. Ezt a köztes szoftvert használják a kérelem szűrésére és a JWT token érvényesítésére. Ha a token érvénytelen, nincs jelen vagy lejárt, a köztes szoftver kivételt dob, amelyet elkaphatunk.

A Laravel 5-ben a app/Exceptions/Handler.php fájl. A render használatával függvény segítségével HTTP-válaszokat hozhatunk létre a dobott kivétel alapján.

public function render($request, Exception $e) { if ($e instanceof TymonJWTAuthExceptionsTokenInvalidException) { return response(['Token is invalid'], 401); } if ($e instanceof TymonJWTAuthExceptionsTokenExpiredException) { return response(['Token has expired'], 401); } return parent::render($request, $e); }

Ha a felhasználó hitelesítve van, és a token érvényes, akkor a korlátozott adatokat a JSON-on keresztül biztonságosan visszaadhatjuk a frontendnek.

Korlátozott erőforrások lekérése az API aldomainről

A következő JSON internetes token példában más megközelítést alkalmazunk a tokenek érvényesítésére. A jwt-auth használata helyett köztes szoftver, a kivételeket kézzel fogjuk kezelni. Amikor egy POST -t készítünk kérelmet egy API-kiszolgálóhoz api.jwt.dev/v1/restricted, kereszt-eredetű kérelmet küldünk, és engedélyeznünk kell a CORS-t a háttérprogramban. Szerencsére a CORS-t már konfiguráltuk a config/cors.php -ban fájl.

Route::group(['domain' => 'api.jwt.dev', 'prefix' => 'v1'], function () { Route::get('/restricted', function () { try { JWTAuth::parseToken()->toUser(); } catch (Exception $e) { return Response::json(['error' => $e->getMessage()], HttpResponse::HTTP_UNAUTHORIZED); } return ['data' => 'This has come from a dedicated API subdomain with restricted access.']; }); });

AngularJS frontend példa

Az AngularJS-t front-endként használjuk, támaszkodva az API-hívásokra a Laravel háttér-hitelesítési kiszolgálóhoz a felhasználói hitelesítés és a mintaadatok, valamint az API-kiszolgáló számára a kereszt-eredetű példaadatokhoz. Amint a projektünk kezdőlapjára lépünk, a háttérrendszer a resources/views/spa.blade.php nézet, amely elindítja az Angular alkalmazást.

Itt található az Angular alkalmazás mappa felépítése:

public/ |-- css/ `-- bootstrap.superhero.min.css |-- lib/ |-- loading-bar.css |-- loading-bar.js `-- ngStorage.js |-- partials/ |-- home.html |-- restricted.html |-- signin.html `-- signup.html `-- scripts/ |-- app.js |-- controllers.js `-- services.js

A szögletes alkalmazás indítása

spa.blade.php tartalmazza az alkalmazás futtatásához szükséges alapvető elemeket. A stílushoz a Twitter Bootstrap programot fogjuk használni, az egyedi témával együtt Bootswatch . Ahhoz, hogy némi vizuális visszajelzést kapjunk az AJAX hívás kezdeményezésekor, a szögletöltő rúd parancsfájl, amely elfogja az XHR kéréseket és létrehoz egy betöltősávot. A fejléc szakaszban a következő stíluslapok találhatók:

ngStorage

A jelölésünk láblécében találhatók hivatkozások a könyvtárakra, valamint az Angular modulok, vezérlők és szolgáltatások egyedi szkriptjei.

Authorization

Használjuk token könyvtár az AngularJS számára, a tokenek mentéséhez a böngésző helyi tárolójába, hogy minden kérésre elküldhessük a Toggle navigation JWT Angular example

  Restricted area 
  Sign in 
  Sign up 
  Logout

fejléc.

A termelési környezetben természetesen az összes szkriptfájlunkat és stíluslapunkat tömörítjük és egyesítjük a teljesítmény javítása érdekében.

Létrehoztam egy navigációs sávot a Bootstrap segítségével, amely megváltoztatja a megfelelő linkek láthatóságát, a felhasználó bejelentkezési állapotától függően. A bejelentkezési állapotot a app.js jelenléte határozza meg változó a vezérlő hatókörében.

angular.module('app', [ 'ngStorage', 'ngRoute', 'angular-loading-bar' ]) .constant('urls', { BASE: 'http://jwt.dev:8000', BASE_API: 'http://api.jwt.dev:8000/v1' }) .config(['$routeProvider', '$httpProvider', function ($routeProvider, $httpProvider) { $routeProvider. when('/', { templateUrl: 'partials/home.html', controller: 'HomeController' }). when('/signin', { templateUrl: 'partials/signin.html', controller: 'HomeController' }). when('/signup', { templateUrl: 'partials/signup.html', controller: 'HomeController' }). when('/restricted', { templateUrl: 'partials/restricted.html', controller: 'RestrictedController' }). otherwise({ redirectTo: '/' });

útvonalválasztás

Van egy fájlunk, amelynek neve: HomeController amely felelős az összes elülső útvonalunk konfigurálásáért.

RestrictedController

Itt láthatjuk, hogy négy útvonalat definiáltunk, amelyeket a Authorization kezel vagy $httpProvider.interceptors.push(['$q', '$location', '$localStorage', function ($q, $location, $localStorage) { return { 'request': function (config) { config.headers = config.headers || {}; if ($localStorage.token) { config.headers.Authorization = 'Bearer ' + $localStorage.token; } return config; }, 'responseError': function (response) { if (response.status === 401 || response.status === 403) { $location.path('/signin'); } return $q.reject(response); } }; }]); . Minden útvonal részleges HTML nézetnek felel meg. Meghatároztunk két állandót is, amelyek URL-eket tartalmaznak a háttérprogram HTTP-kérelmeihez.

Kérjen elfogót

Az AngularJS $ http szolgáltatása lehetővé teszi számunkra, hogy kommunikáljunk a háttérrendszerrel és HTTP kéréseket küldjünk. Esetünkben minden HTTP-kérést elfogni akarunk, és controllers.js fejléc, amely a JWT-t tartalmazza, ha a felhasználó hitelesítve van. Elfogó segítségével globális HTTP hibakezelőt is létrehozhatunk. Itt van egy példa elfogónkra, amely tokent ad be, ha elérhető a böngésző helyi tárhelyén.

HomeController

Vezérlők

A RestrictedController -ban fájlban két vezérlőt definiáltunk az alkalmazásunkhoz: HomeController és Auth. angular.module('app') .controller('HomeController', ['$rootScope', '$scope', '$location', '$localStorage', 'Auth', function ($rootScope, $scope, $location, $localStorage, Auth) { function successAuth(res) { $localStorage.token = res.token; window.location = '/'; } $scope.signin = function () { var formData = { email: $scope.email, password: $scope.password }; Auth.signin(formData, successAuth, function () { $rootScope.error = 'Invalid credentials.'; }) }; $scope.signup = function () { var formData = { email: $scope.email, password: $scope.password }; Auth.signup(formData, successAuth, function () { $rootScope.error = 'Failed to signup'; }) }; $scope.logout = function () { Auth.logout(function () { window.location = '/' }); }; $scope.token = $localStorage.token; $scope.tokenClaims = Auth.getTokenClaims(); }]) kezeli a bejelentkezés, a regisztráció és a kijelentkezés funkcióit. Átadja a felhasználónév és jelszó adatait a bejelentkezési és regisztrációs űrlapokról a RestrictedController szolgáltatás, amely HTTP kéréseket küld a háttérprogramnak. Ezután elmenti a tokent a helyi tárhelyre, vagy hibaüzenetet jelenít meg, a háttérrendszer válaszától függően.

getRestrictedData

getApiData ugyanúgy viselkedik, csak az Data használatával szerzi be az adatokat és .controller('RestrictedController', ['$rootScope', '$scope', 'Data', function ($rootScope, $scope, Data) { Data.getRestrictedData(function (res) { $scope.data = res.data; }, function () { $rootScope.error = 'Failed to fetch restricted content.'; }); Data.getApiData(function (res) { $scope.api = res.data; }, function () { $rootScope.error = 'Failed to fetch restricted API content.'; }); }]); függvények a Authorization szolgáltatás.

tokenClaims

A háttérprogram csak akkor felel a korlátozott adatok kiszolgálásáért, ha a felhasználó hitelesítve van. Ez azt jelenti, hogy a korlátozott adatokkal történő válaszadáshoz az adatok iránti kérelemnek érvényes JWT-t kell tartalmaznia a getTokenClaims fejléc vagy lekérdezési karakterlánc. Ha nem ez a helyzet, akkor a kiszolgáló 401-es jogosulatlan hibaállapot-kóddal válaszol.

Auth Service

Az Auth szolgáltatás felelős a bejelentkezésért és a HTTP-kérelmek regisztrálásáért a háttérbe. Ha a kérés sikeres, a válasz tartalmazza az aláírt tokent, amelyet azután base64 dekódol, és a mellékelt token igénylési információkat a angular.module('app') .factory('Auth', ['$http', '$localStorage', 'urls', function ($http, $localStorage, urls) { function urlBase64Decode(str) { var output = str.replace('-', '+').replace('_', '/'); switch (output.length % 4) { case 0: break; case 2: output += '=='; break; case 3: output += '='; break; default: throw 'Illegal base64url string!'; } return window.atob(output); } function getClaimsFromToken() { var token = $localStorage.token; var user = {}; if (typeof token !== 'undefined') { var encoded = token.split('.')[1]; user = JSON.parse(urlBase64Decode(encoded)); } return user; } var tokenClaims = getClaimsFromToken(); return { signup: function (data, success, error) { $http.post(urls.BASE + '/signup', data).success(success).error(error) }, signin: function (data, success, error) { $http.post(urls.BASE + '/signin', data).success(success).error(error) }, logout: function (success) { tokenClaims = {}; delete $localStorage.token; success(); }, getTokenClaims: function () { return tokenClaims; } }; } ]); változó. Ezt a angular.module('app') .factory('Data', ['$http', 'urls', function ($http, urls) { return { getRestrictedData: function (success, error) { $http.get(urls.BASE + '/restricted').success(success).error(error) }, getApiData: function (success, error) { $http.get(urls.BASE_API + '/restricted').success(success).error(error) } }; } ]); segítségével továbbítja a vezérlőnek funkció.

|_+_|

Adatszolgáltatás

Ez egy egyszerű szolgáltatás, amely kéréseket küld a hitelesítési kiszolgálónak, valamint az API-kiszolgálónak néhány, korlátozottan korlátozott adatra. Elküldi a kérést, és sikeres és hibás visszahívásokat delegál a vezérlőhöz.

|_+_|

Túl ezen a JSON web Token bemutatón

A token alapú hitelesítés lehetővé teszi számunkra, hogy olyan független rendszereket állítsunk össze, amelyek nem kötődnek egy adott hitelesítési sémához. A tokent bárhol elő lehet állítani, és bármely olyan rendszerben fel lehet használni, amely ugyanazt a titkos kulcsot használja a token aláírásához. Mobilra készek, és nem követelik meg, hogy sütiket használjunk.

A JSON web tokenek az összes népszerű programozási nyelven működnek, és gyorsan egyre népszerűbbek. Olyan vállalatok támogatják őket, mint a Google, a Microsoft és a Zendesk. Az Internet Engineering Task Force (IETF) szabványos specifikációja az még mindig a piszkozati változatban és a jövőben kissé megváltozhat.

A JWT-kről még mindig sok mindent le kell fedni, például arról, hogyan kell kezelni Biztonság részletek és frissítő tokenek, amikor lejárnak, de a JSON Web Token oktatóanyagnak bemutatnia kell a JWT-k használatának alapvető használatát és ami még ennél is fontosabb.

Az alapok megértése

Mi az a hordozójelző?

Ez egy JWT-re vonatkozik, amelyet az Engedélyezés nevű HTTP fejlécen keresztül továbbítunk, „Bearer $ your_token_here” karakterlánc formátumban.

Mi a JWT?

A JWT a JSON Web Token rövidítés, a modern webalkalmazásokban alkalmazott általános hitelesítési taktikát jelenti.

Hogyan működik a JSON?

A JSON egyszerűen olyan adatformátum, amely nagyon hasonlít a JavaScript által engedélyezett szó szerinti formátumra. Ez egy hierarchikus formátum, amely beágyazott objektumokat és tömböket, valamint string és szám literálokat tesz lehetővé.