Ühe lehe rakenduste, mobiilirakenduste ja RESTful API teenuste populaarsuse kasvuga veebiarendajad kirjuta back-end kood on oluliselt muutunud. Selliste tehnoloogiate abil nagu AngularJS ja BackboneJS ei kuluta me enam palju aega juurdehindluse loomisele, vaid ehitame API-sid, mida meie esiotsa rakendused tarbivad. Meie back-end on rohkem seotud äriloogikaga ja andmetega, samas kui esitlusloogika liigutatakse ainult esiotsa või mobiilirakendustesse. Need muudatused on viinud uute viisideni autentimise juurutamiseks tänapäevastes rakendustes.
Autentimine on iga veebirakenduse üks olulisemaid osi. Aastakümneid olid küpsised ja serveripõhine autentimine lihtsaim lahendus. Autentimise käsitlemine tänapäevastes mobiilirakendustes ja ühe lehe rakendustes võib olla keeruline ja nõuab paremat lähenemist. Tuntuimad lahendused API-de autentimisprobleemidele on OAuth 2.0 ja JSON-i veebimärk (JWT).
Mis on JWT täpselt enne selle JSON-i veebimärgi õpetuse alustamist?
JSON-i veebimärki kasutatakse digitaalse allkirja abil kontrollitava ja usaldusväärse teabe edastamiseks. See sisaldab kompaktset ja URL-i jaoks ohutut JSON-objekti, mis on autentsuse kontrollimiseks krüptograafiliselt allkirjastatud ja mida saab krüptida ka siis, kui kasulik koormus sisaldab tundlikku teavet.
Kompaktse struktuuri tõttu kasutatakse JWT-d tavaliselt HTTP Authorization
päised või URL-i päringu parameetrid.
JWT on kujutatud järjestusena base64url kodeeritud väärtused, mis on eraldatud punktimärkidega.
Siin on JWT märgi näide:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJpc3MiOiJ0b3B0YWwuY29tIiwiZXhwIjoxNDI2NDIwODAwLCJodHRwOi8vdG9wdGFsLmNvbS9qd3RfY2xhaW1zL2lzX2FkbWluIjp0cnVlLCJjb21wYW55IjoiVG9wdGFsIiwiYXdlc29tZSI6dHJ1ZX0. yRQYnWzskCZUxPwaQupWkiUzKELZ49eM7oWxAQK_ZXw
Päis sisaldab loa metaandmeid ja sisaldab minimaalselt allkirja tüüpi ja krüpteerimisalgoritmi. (Võite kasutada a JSON-vormindaja tööriist objekti JSON täpsustamiseks.)
Näite päis
{ 'alg': 'HS256', 'typ': 'JWT' }
See JWT näite päis deklareerib, et kodeeritud objekt on JSON-i veebitunnus ja see on allkirjastatud HMAC SHA-256 algoritmi abil.
Kui see on base64 kodeeritud, on meil JWT esimene osa.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
JWT kontekstis saab nõuet määratleda nii üksuse (tavaliselt kasutaja) kohta käiva avaldusena kui ka täiendava metaandmena märgi enda kohta. Nõue sisaldab teavet, mida me soovime edastada, ja mida server saab kasutada JSON-i veebimärgi autentimise õigeks käsitsemiseks. Meil on mitu väidet; nende hulka kuuluvad registreeritud nõuete nimed, avalike nõuete nimed ja eranõuete nimed.
Registreeritud JWT nõuded
Need on nõuded, mis on registreeritud IANA JSON-i veebimärgi nõuete register . Need JWT väited ei ole mõeldud kohustuslikena, vaid pigem lähtepunktiks kasulikele, koostalitlusvõimelistele väidetele.
Need sisaldavad:
Avalikud nõuded
Avalikel väidetel peavad olema kokkupõrkekindlad nimed. Tehes nimest URI või URN, välditakse JWT-de nimede kokkupõrkeid, kus saatja ja vastuvõtja ei kuulu suletud võrku.
Avaliku pretensiooninime näide võib olla: https://www.toptal.com/jwt_claims/is_admin
ja parimaks tavaks on paigutada sellesse kohta fail, mis kirjeldaks nõuet, nii et selle dokumenteerimiseks võiks viidata.
Eranõuded
Eranõuete nimesid võib kasutada kohtades, kus JWT-sid vahetatakse ainult suletud keskkonnas teadaolevate süsteemide vahel, näiteks ettevõtte sees. Need on väited, mida saame ise määratleda, näiteks kasutajatunnused, kasutajarollid või mis tahes muu teave.
Nõudenimede kasutamine, millel võib olla suletud või privaatsüsteemist väljaspool vastuolulisi semantilisi tähendusi, satuvad kokkupõrke alla, seega kasutage neid ettevaatusega.
Oluline on märkida, et soovime hoida veebimärki võimalikult väikesena, seega kasutage avalikes ja eraviisilistes nõuetes ainult vajalikke andmeid.
JWT kasuliku koormuse näide
{ 'iss': 'toptal.com', 'exp': 1426420800, 'https://www.toptal.com/jwt_claims/is_admin': true, 'company': 'ApeeScape', 'awesome': true }
Sellel kasulikul koormusel on kaks registreeritud nõuet, üks avalik ja kaks eranõuet. Kui see on base64 kodeeritud, on meil JWT teine osa.
eyJpc3MiOiJ0b3B0YWwuY29tIiwiZXhwIjoxNDI2NDIwODAwLCJodHRwOi8vdG9wdGFsLmNvbS9qd3RfY2xhaW1zL2lzX2FkbWluIjp0cnVlLCJjb21wYW55IjoiVG9wdGFsIiwiYXdlc29tZSI6dHJ1ZX0
JWT standard järgib lõpliku allkirjastatud loa genereerimiseks JSON-i veebiallkirja (JWS) spetsifikatsiooni. Selle genereerimiseks ühendatakse kodeeritud JWT päis ja kodeeritud JWT kasulikkus ning allkirjastatakse see tugeva krüpteerimisalgoritmi, näiteks HMAC SHA-256 abil. Allkirja salajast võtit hoiab server, nii et see saab olemasolevaid märke kinnitada ja uutele alla kirjutada.
$encodedContent = base64UrlEncode(header) + '.' + base64UrlEncode(payload); $signature = hashHmacSHA256($encodedContent);
See annab meile JWT viimase osa.
yRQYnWzskCZUxPwaQupWkiUzKELZ49eM7oWxAQK_ZXw
Inimestevaheliste rünnakute vältimiseks on oluline kasutada TLS / SSL-i koos JWT-ga. Enamasti piisab sellest JWT-i kasuliku koorma krüptimiseks, kui see sisaldab tundlikku teavet. Siiski, kui soovime lisada täiendava kaitsekihi, saame JWT kasuliku koormuse ise krüptida, kasutades JSON-i veebikrüptimine (PLAY) spetsifikatsioon.
Muidugi, kui soovime vältida JWE kasutamise täiendavat lisakulu, on teine võimalus lihtsalt hoida tundlikku teavet oma andmebaasis ja kasutada oma märki serverile täiendavate API-kõnede jaoks alati, kui peame tundlikele andmetele juurde pääsema.
Enne kui näeme kõiki JWT-autentimise kasutamise eeliseid, peame vaatama, kuidas autentimist on varem tehtud.
Kuna HTTP-protokoll on kodakondsuseta, peab olema olemas kasutajainfo salvestamise mehhanism ja viis kasutaja autentimiseks igal järgmisel nõudmisel pärast sisselogimist. Enamik veebisaite kasutab küpsiseid kasutaja seansi ID salvestamiseks.
Kuidas see töötab
Brauser esitab serverile POST-päringu, mis sisaldab kasutaja identifikaatorit ja parooli. Server vastab küpsisega, mis on seatud kasutaja brauserisse, ja sisaldab kasutaja tuvastamiseks seansi ID-d.
Iga järgneva taotluse korral peab server selle seansi leidma ja deserialiseerima, kuna kasutajaandmed salvestatakse serverisse.
Raske skaleerida : Server peab looma kasutaja jaoks seansi ja säilitama selle kusagil serveris. Seda saab teha mälus või andmebaasis. Kui meil on hajutatud süsteem, peame veenduma, et kasutame eraldi seansi salvestusruumi, mis pole rakendusserveriga ühendatud.
Päritoluüleste päringute jagamine (CORS) : Kui kasutate AJAX-i kõnesid ressursi toomiseks teisest domeenist („ristpõhimõte”), võib meil tekkida probleeme keelatud taotlustega, kuna vaikimisi ei sisalda HTTP-päringud päritolu päringute päringuid.
Ühendamine veebiraamistikuga : Serveripõhise autentimise kasutamisel oleme seotud meie raamistiku autentimisskeemiga. Erinevates programmeerimiskeeltes kirjutatud erinevate veebiraamistike vahel on seansiandmete jagamine tõesti raske või isegi võimatu.
Märgipõhine / JWT-autentimine on kodakondsuseta, mistõttu pole seansil vaja kasutajainfot salvestada. See annab meile võimaluse oma rakendust skaleerida muretsemata, kuhu kasutaja on sisse loginud. Saame sama luba kasutada turvalise ressursi toomiseks muust domeenist kui see, kuhu oleme sisse logitud.
Kuidas JSON-i veebimärgid töötavad
Brauser või mobiiliklient esitab autentimisserverile päringu, mis sisaldab kasutaja sisselogimisteavet. Autentimisserver genereerib uue JWT-juurdepääsuloa ja tagastab selle kliendile. Piiratud ressurssi iga päringu korral saadab klient juurdepääsuloa päringustringis või Authorization
päis. Seejärel kontrollib server luba ja kui see kehtib, tagastab turvalise ressursi kliendile.
Autentimisserver saab märgile alla kirjutada mis tahes turvalise allkirjaviisi abil. Näiteks saab kasutada sümmeetrilise võtme algoritmi, näiteks HMAC SHA-256, kui on olemas turvaline kanal salajase võtme jagamiseks kõigi osapoolte vahel. Alternatiivina võib kasutada ka asümmeetrilist avaliku võtme süsteemi, näiteks RSA, mis välistab vajaduse võtmete edasiseks jagamiseks.
Kodakondsuseta, hõlpsam skaleerida : Luba sisaldab kogu teavet kasutaja tuvastamiseks, välistades vajaduse seansi oleku järele. Kui kasutame koormuse tasakaalustajat, võime kasutaja edastada igale serverile, selle asemel, et olla seotud sama serveriga, kuhu sisse logisime.
Korduvkasutus : Meil võib olla palju eraldi servereid, mis töötavad mitmel platvormil ja domeenil, kasutades sama autentimist kasutaja autentimiseks. Rakendust, mis jagab õigusi teise rakendusega, on lihtne ehitada.
JWT turvalisus : Kuna me ei kasuta küpsiseid, ei pea me kaitsma saididevaheliste taotluste võltsimise (CSRF) rünnakute eest. Peaksime ikkagi oma märgid krüpteerima JWE abil, kui peame sellesse lisama tundlikku teavet, ja edastama oma märgid HTTPS-i kaudu, et vältida keskel olevate inimeste rünnakuid.
Performance : Iga päringu seansi leidmiseks ja deserialiseerimiseks pole serveripoolset otsingut. Ainus asi, mida me peame tegema, on loa valideerimiseks ja selle sisu sõelumiseks arvutada HMAC SHA-256.
Selles JWT-õpetuses näitan, kuidas juurutada JSON-i veebimärkide abil põhiline autentimine kahes populaarses veebitehnoloogias: Laravel 5 taustaprogrammi jaoks ja AngularJS frontend ühe lehe rakenduse (SPA) näitena. (Leiate kogu demo siin ja lähtekood see GitHubi hoidla et saaksite juhendamist jälgida.)
Selles JSON-i veebimärgi näites ei kasutata nõuetes edastatud teabe konfidentsiaalsuse tagamiseks mingisugust krüptimist. Praktikas on see sageli okei, sest TLS / SSL krüpteerib päringu. Kui märgis hakkab sisaldama tundlikku teavet, näiteks kasutaja sotsiaalkindlustuse numbrit, peaks see olema krüptitud ka JWE abil.
Kasutame Laraveli kasutaja registreerimiseks, kasutajaandmete andmebaasi säilitamiseks ja piiratud andmete edastamiseks, mis vajavad rakenduse Angular tarbimiseks autentimist. Loome API alamdomeeni näite, et simuleerida ka päritoluülese ressursi jagamist (CORS).
Installimine ja projekti alglaadimine
Laraveli kasutamiseks peame installima Helilooja meie masina paketihaldur. Laravelis arendades soovitan kasutada Vagranti pakendatud Laraveli kodutalu pakendit. See tagab meile täieliku arenduskeskkonna, hoolimata meie opsüsteemist.
Lihtsaim viis meie JWT Laraveli rakenduse käivitamiseks on kasutada helilooja paketti Laravel Installer.
composer global require 'laravel/installer=~1.1'
Nüüd oleme kõik valmis laravel new jwt
käivitades uue Laraveli projekti loomiseks.
Selle protsessi kohta küsimuste saamiseks pöörduge ametniku poole Laraveli dokumentatsioon .
Pärast põhirakenduse Laravel 5 loomist peame seadistama oma Homestead.yaml
, mis konfigureerib meie kohaliku keskkonna jaoks kaustade kaardistused ja domeenide konfiguratsiooni.
Näide Homestead.yaml
fail:
--- 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
Kui oleme oma Vagranti kasti käivitanud vagrant up
-ga käsu ja logisime sinna sisse, kasutades vagrant ssh
, navigeerime eelnevalt määratletud projekti kataloogi. Ülaltoodud näites oleks see /home/vagrant/coding/jwt
. Nüüd saame joosta php artisan migrate
vajalike kasutajate tabelite loomiseks meie andmebaasis.
Helilooja sõltuvuste installimine
Õnneks töötab Laraveli kallal arendajate kogukond, kes hooldab paljusid suurepäraseid pakette, mida saame oma rakendust uuesti kasutada ja laiendada. Selles näites kasutame tymon/jwt-auth
, autor Sean Tymon, serveripoolsete märkide käsitsemise eest ja barryvdh/laravel-cors
, autor Barry vd. Heuvel, CORS-i käsitsemiseks.
jwt-auth
Nõua tymon/jwt-auth
pakendis meie composer.json
ja värskendage meie sõltuvusi.
composer require tymon/jwt-auth 0.5.*
Lisage JWTAuthServiceProvider
meie app/config/app.php
pakkujate massiiv.
'TymonJWTAuthProvidersJWTAuthServiceProvider'
Järgmisena jaotises app/config/app.php
faili alla aliases
massiivi, lisame JWTAuth
fassaad.
'JWTAuth' => 'TymonJWTAuthFacadesJWTAuth'
Lõpuks soovime avaldada paketi config järgmise käsu abil: php artisan config: publish tymon / jwt-auth
JSON-i veebimärgid krüpteeritakse salajase võtme abil. Selle võtme saame genereerida, kasutades nuppu php artisan jwt:generate
käsk. See asetatakse meie config/jwt.php
sisse faili. Tootmiskeskkonnas ei soovi me aga kunagi oma paroole ega API võtmeid konfiguratsioonifailides. Selle asemel peaksime paigutama need serverikeskkonna muutujatesse ja viitama konfiguratsioonifailis env
funktsioon. Näiteks:
'secret' => env('JWT_SECRET')
Saame selle paketi ja kõigi selle konfiguratsiooniseadete kohta lisateavet Githubis .
laravel-cors
Nõua barryvdh/laravel-cors
pakendis meie composer.json
ja värskendage meie sõltuvusi.
composer require barryvdh/laravel-cors [email protected]
Lisage CorsServiceProvider
meie app/config/app.php
pakkujate massiiv.
'BarryvdhCorsCorsServiceProvider'
Seejärel lisage vahevara meie app/Http/Kernel.php
.
'BarryvdhCorsMiddlewareHandleCors'
Avaldage konfiguratsioon lokaalses config/cors.php
faili php artisan vendor:publish
abil käsk.
Näide cors.php
faili konfiguratsioon:
return [ 'defaults' => [ 'supportsCredentials' => false, 'allowedOrigins' => [], 'allowedHeaders' => [], 'allowedMethods' => [], 'exposedHeaders' => [], 'maxAge' => 0, 'hosts' => [], ], 'paths' => [ 'v1/*' => [ 'allowedOrigins' => ['*'], 'allowedHeaders' => ['*'], 'allowedMethods' => ['*'], 'maxAge' => 3600, ], ], ];
HTTP-päringute suunamine ja käitlemine
Lühiduse huvides panen kogu oma koodi faili route.php sisse, mis vastutab Laraveli marsruutimise ja kontrolleritele päringute delegeerimise eest. Me loome tavaliselt spetsiaalsed kontrollerid kõigi meie HTTP-päringute töötlemiseks ja hoiame oma koodi modulaarsena ja puhtana.
Laadime oma AngularJS SPA vaate kasutades
Route::get('/', function () { return view('spa'); });
Kasutaja registreerimine
Kui teeme POST
taotlus /signup
kasutajanime ja parooliga proovime luua uue kasutaja ja salvestada see andmebaasi. Pärast kasutaja loomist luuakse ja tagastatakse JSON-i vastuse kaudu JWT.
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')); });
Kasutaja sisselogimine
Kui teeme POST
taotlus /signin
kasutajanime ja parooliga kontrollime, kas kasutaja on olemas ja tagastab JSON-i vastuse kaudu JWT.
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')); });
Piiratud ressursi toomine samale domeenile
Kui kasutaja on sisse logitud, saame tuua piiratud ressursi. Olen loonud marsruudi /restricted
mis simuleerib ressurssi, mis vajab autentitud kasutajat. Selleks tuleb taotlus Authorization
päises või päringustringis peab olema tagatise kinnitamiseks JWT.
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() ] ]); } ]);
Selles näites kasutan jwt-auth
jwt-auth
pakutav vahevara pakk, kasutades 'before' => 'jwt-auth'
. Seda vahevara kasutatakse päringu filtreerimiseks ja JWT-loa valideerimiseks. Kui luba on vale, seda pole või see on aegunud, loob vahevara erandi, mille saame kätte saada.
Laravel 5-s saame erandeid tabada, kasutades app/Exceptions/Handler.php
faili. Kasutades render
funktsiooni saame visatud erandi põhjal luua HTTP-vastuseid.
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); }
Kui kasutaja on autentitud ja luba on kehtiv, võime piiratud andmed turvaliselt esipaneelile JSON-i kaudu tagastada.
Piiratud ressursside toomine API alamdomeenilt
Järgmises JSON-i veebimärgi näites võtame märgi valideerimisel kasutusele teistsuguse lähenemisviisi. Selle asemel, et kasutada jwt-auth
vahevara, käsitleme erandeid käsitsi. Kui teeme POST
taotlus API-serverile api.jwt.dev/v1/restricted
, esitame rist-päritolustaotluse ja peame lubama CORS-i taustaprogrammis. Õnneks oleme CORS-i juba seadistanud config/cors.php
-s faili.
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.']; }); });
Kasutame kasutajaliidesena AngularJS-i, tuginedes API väljakutsetele Laraveli taguotsa autentimisserverile kasutajate autentimiseks ja näidisandmeteks ning pluss API serveriks päritolu ristandmete näidisandmete jaoks. Kui me läheme oma projekti avalehele, teenib taustaprogramm resources/views/spa.blade.php
vaade, mis käivitab rakenduse Angular.
Siin on rakenduse Angular kaustade struktuur:
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
Nurgarakenduse alglaadimine
spa.blade.php
sisaldab rakenduse käitamiseks vajalikke hädavajalikke asju. Kasutame stiiliks Twitter Bootstrapi koos kohandatud teemaga Saapakell . AJAX-kõne tegemisel visuaalse tagasiside saamiseks kasutame nurk-laadimisvarda skript, mis võtab vastu XHR-i päringud ja loob laadimisriba. Päise jaotises on meil järgmised stiililehed:
ngStorage
Meie märgistuse jalus sisaldab viiteid teekidele, samuti meie kohandatud skripte nurgamoodulite, kontrollerite ja teenuste jaoks.
Authorization
Me kasutame token
kogu AngularJS-i jaoks, et salvestada märgid brauseri kohalikku salvestusruumi, et saaksime selle iga päringu korral Toggle navigation JWT Angular example
päis.
Tootmiskeskkonnas minimeerime ja kombineerime jõudluse parandamiseks loomulikult kõik oma skriptifailid ja stiililehed.
Olen loonud Bootstrapi abil navigeerimisriba, mis muudab sobivate linkide nähtavust sõltuvalt kasutaja sisselogimisolekust. Sisselogimisoleku määrab app.js
olemasolu muutuja kontrolleri reguleerimisalas.
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: '/' });
Marsruutimine
Meil on fail nimega HomeController
mis vastutab kõigi meie esiotsa marsruutide seadistamise eest.
RestrictedController
Siit näeme, et oleme määranud neli marsruuti, mida haldab kumbki Authorization
või $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); } }; }]);
. Iga marsruut vastab osalisele HTML-i vaatele. Oleme määranud ka kaks konstandi, mis sisaldavad URL-e meie HTTP-päringute jaoks taustaprogrammile.
Taotle pealtkuulajat
AngularJS-i teenus $ http võimaldab meil taustaprogrammiga suhelda ja HTTP-päringuid teha. Meie juhul tahame iga HTTP-päringu pealt kuulata ja sisestada controllers.js
päis, mis sisaldab meie JWT-d, kui kasutaja on autentitud. Samuti võime blokeerija abil luua ülemaailmse HTTP-tõrke käitleja. Siin on näide meie pealtkuulajast, kes süstib märgi, kui see on saadaval brauseri kohalikus salvestusruumis.
HomeController
Kontrollerid
Väljal RestrictedController
faili, oleme oma rakenduse jaoks määranud kaks kontrollerit: HomeController
ja 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(); }])
tegeleb sisselogimise, registreerumise ja väljalogimisega. See edastab kasutajanime ja parooli andmed sisselogimis- ja registreerimisvormidelt RestrictedController
teenus, mis saadab HTTP-päringud taustaprogrammile. Seejärel salvestab see loa kohalikku salvestusruumi või kuvab veateate, sõltuvalt taustaprogrammi vastusest.
getRestrictedData
getApiData
käitub samamoodi, ainult see tõmbab andmed Data
abil ja .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.'; }); }]);
funktsioonid Authorization
teenus.
tokenClaims
Taustaprogramm vastutab piiratud andmete esitamise eest ainult siis, kui kasutaja on autentitud. See tähendab, et piiratud andmetega vastamiseks peab nende andmete taotlus sisaldama kehtivat JWT-d getTokenClaims
päis või päring string. Kui see pole nii, vastab server 401 volitamata tõrke olekukoodiga.
Autentimisteenus
Autentimisteenus vastutab backendisse sisselogimise ja HTTP-päringute registreerimise eest. Kui taotlus on edukas, sisaldab vastus allkirjastatud luba, mis seejärel dekodeeritakse base64, ja lisatud luba nõuete teave salvestatakse kausta 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; } }; } ]);
muutuv. See edastatakse kontrollerile 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) } }; } ]);
kaudu funktsioon.
|_+_|
Andmeteenus
See on lihtne teenus, mis esitab mõnele mannekeeniga piiratud andmetele päringuid nii autentimisserverile kui ka API-serverile. See teeb päringu ning delegeerib kontrollerile edukuse ja tõrke tagasihelistamise.
|_+_|
Märgipõhine autentimine võimaldab meil luua lahutatud süsteeme, mis pole seotud kindla autentimisskeemiga. Luba võidakse genereerida kõikjal ja tarbida igas süsteemis, mis kasutab luba allkirjastamiseks sama salajast võtit. Need on mobiilseadmetele valmis ja ei nõua meilt küpsiste kasutamist.
JSON-i veebimärgid töötavad kõigis populaarsetes programmeerimiskeeltes ja on kiiresti populaarsust kogumas. Neid toetavad sellised ettevõtted nagu Google, Microsoft ja Zendesk. Nende Interneti-inseneri töörühma (IETF) standardspetsifikatsioon on endiselt mustandversioonis ja võib tulevikus veidi muutuda.
JWT-de kohta on veel palju vaja käsitleda, näiteks kuidas neid käsitleda turvalisus üksikasjad ja värskendavad märgid, kui need aeguvad, kuid JSON-i veebimärgi õpetus peaks näitama JWT-de põhikasutust ja veelgi olulisemat eelist.
See viitab JWT-le, mis edastatakse HTTP-päise kaudu, mida nimetatakse autoriseerimiseks, stringivormingus 'Bearer $ your_token_here'.
JWT tähistab JSON-i veebimärki, mis on tänapäevastes veebirakendustes levinud autentimistaktika.
JSON on lihtsalt andmevorming, mis sarnaneb suuresti JavaScripti lubatud sõnasõnalise vorminguga. See on hierarhiline vorming, mis võimaldab pesastatud objekte ja massiive, samuti stringi- ja numbriliite.