Ora che abbiamo compreso l'autenticazione basata su token utilizzando i token Web JSON
e abbiamo anche compreso i vantaggi dell'utilizzo di questo approccio.
Il fatto che ora stiamo costruendo un server basato su API Rest,
in questo corso significa che
l'autenticazione basata su token Web JSON
è più adatta per questo server che stiamo costruendo.
Quindi, aggiorniamo il nostro server API Rest per fare uso di token Web JSON in questo esercizio.
Per iniziare ad aggiornare il server sul tuo terminale,
installiamo prima il token Web JSON e il modulo del nodo JWT passaporto.
Quindi, al prompt digitare npm, installa,
passaporto JWT JSON Web Token e meno salva.
Come puoi vedere, sto usando JSON Web Token 8.3.0 e passaporto JWT 4.0.0 in questo corso.
Ora che abbiamo completato l'installazione andiamo avanti e aggiorniamo il nostro server express.
Andando ora al nostro codice,
aggiungiamo un file chiamato
conflict.js nella cartella principale del nostro progetto.
Ora, questo file conflict.js ho intenzione di usarlo per
memorizzare alcune informazioni di configurazione per il nostro server.
Ora, questo è un modo per centralizzare tutta la configurazione per il nostro server.
In questo file conflict.js,
lasciami esportare un oggetto JSON qui.
Quindi diremo, SecretKey,
e questo è dove
specificherò la chiave segreta che userò per firmare il mio token Web JSON,
e lasciatemi anche specificare un URL Mongo qui,
che sarà l'URL per il
mio server MongoDB localhost 27017.
Una volta che abbiamo completato questo,
allora andremo al file authenticate.js,
e nel file authenticate.js
ora creeremo la strategia JWT.
Questa è la strategia di token web JSON fornita dal
nostro modulo nodo JWT passaporto che abbiamo appena incluso e quindi diremo,
generatività strategia passaporto generativity.strategy.
Questo ci fornirà
una strategia basata su token Web JSON per configurare il nostro modulo passaporto,
quindi estrarre JWT, che
otterrò anche dal passaporto JWT.
Avremo bisogno del passaporto JWT,
poi diremo «Estrai JWT».
Quindi importiamo
il modulo JSON Web Token
che abbiamo appena installato.
Una volta che abbiamo importato questi,
andiamo avanti e iniziamo a configurare alcune cose.
Insieme a questi, lasciami importare la configurazione che ho
creato il file config.js che ho appena aggiunto al mio progetto.
Una volta completato questo, lasciami andare avanti e
introdurre alcune funzioni aggiuntive che esporterò da qui.
Diciamo, Exports.getToken,
questa funzione quando fornisci un parametro lì che chiamerò semplicemente utente,
che sarà un oggetto JSON,
questo creerà il token e lo darà per noi.
Per creare il token, useremo il modulo jsonwebtoken che abbiamo appena importato.
Quindi, qui diremo ritorno JWT.sign,
questo ci aiuta a creare il token Web JSON e così dentro che
mi permetterà di fornire il payload e
il payload qui arriva come il parametro qui chiamato utente,
e quindi il secondo parametro è
la chiave segreta o privata che ottengo da config. chiave segreta,
che ho appena configurato un po 'prima.
Possiamo fornire ulteriori opzioni qui.
Un' opzione che ho intenzione di fornire a questo è...
Ok, lasciami andare alla riga successiva qui,
l'opzione che fornirò è ExpiResin.
ExpiResin ti dirà per quanto tempo il jsonwebtoken sarà
valido, quindi in questo caso dico 3.600 che significa 3.600 secondi o circa un'ora.
Un' ora dopo dovrai rinnovare il jsonwebtoken.
Un' ora è abbastanza lunga per essere in grado di testare la nostra applicazione.
È possibile impostare questo per essere molto più lungo se si sceglie di farlo.
In un'applicazione reale potresti impostare questo valore molto più lungo forse
qualche giorno e aspettarti che l'utente si autentichi nuovamente ogni pochi giorni.
Ora, dovremo anche configurare
la strategia basata su jsonwebtoken per la nostra applicazione passaporto.
Quindi, lasciami dichiarare una variabile chiamata opts,
che non è altro che le opzioni che ho intenzione di specificare per la mia strategia basata su JWT.
Quindi diremo opts jwtFromRequest.
Ora questa opzione specifica
come jsonwebtoken deve essere estratto dal messaggio di richiesta in arrivo.
Questo è dove useremo l'estratto JWT.
Questo estratto JWT supporta vari metodi
per estrarre informazioni dall'intestazione.
Dirà da AuthHeader da AuthHeader come token portatore,
dall'intestazione quale schema e così via.
Se leggi la documentazione,
ti dirà vari modi di estrarre il jsonwebtoken.
È possibile passare il token nel corpo del
messaggio di richiesta in arrivo e quindi è possibile estrarlo da lì, è
anche possibile utilizzare estrattori personalizzati e così via.
In questo corso, ho intenzione di utilizzare il metodo più semplice chiamato
dall'intestazione di autenticazione come un token portatore.
Abbiamo già familiarità con
l'intestazione di autenticazione perché come abbiamo usato con
l'autenticazione di base e l'autenticazione basata su cookie in precedenza.
Quindi, userò
lo stesso campo di intestazione nel messaggio di richiesta per portare il jsonwebtoken.
Quindi dirò opts come token portatore jsonwebtoken.
Il prossimo diremo opts.SecretorKey,
questo è il secondo parametro che mi aiuta a
fornire la chiave segreta che userò all'interno della mia strategia per l'accesso.
Quindi questa è l'altra opzione che ho intenzione di specificare qui.
Una volta che sto specificando questi due,
lasciami esportare la strategia Passport
che ho intenzione di configurare qui così diremo ExportJWTPassport,
quindi diremo passport.use.
Ricorda il modo in cui hai specificato la strategia locale in precedenza.
Qui stiamo specificando la strategia basata su JWT,
quindi creeremo una nuova strategia JWT,
ricordare che abbiamo appena importato la strategia JWT
qui che è ciò che useremo per creare una nuova strategia.
Questa strategia JWT prende
l'oggetto options che ho appena creato come primo parametro.
Le opzioni di strategia e la seconda è la funzione di verifica che ho bisogno di fornire,
e quindi la funzione di verifica che ho intenzione di fornire nella riga successiva qui,
diremo FunctionJWT_PayLoad.
Fatto. Quindi, quando viene chiamata questa funzione,
il fatto è il callback fornito dal passaporto.
Quindi, ogni volta che hai il passaporto che stai configurando con una nuova strategia,
devi fornire il secondo parametro fatto.
Attraverso questo parametro fatto,
si passerà indietro le informazioni al passaporto che poi
utilizzerà per caricare le cose sul messaggio di richiesta.
Quindi, quando il passaporto analizza il messaggio di richiesta,
utilizzerà la strategia e quindi estrarre le informazioni,
e quindi caricarlo sul nostro messaggio di richiesta.
Quindi, dal momento che questa è una funzione,
userò solo una funzione freccia qui,
mi sono affezionato alle funzioni di freccia.
Quindi, lasciatemi creare che come una funzione freccia qui,
e all'interno di questa funzione,
definiremo la funzione.
Quindi, cosa facciamo all'interno della funzione?
Lasciami fare un console.log di
payload JWT e poi
lasciami solo disconnettere l'opzione che arriva qui,
l'opzione di payload JWT che viene qui, in
modo che tu possa vedere cosa c'è all'interno del payload JWT.
Quindi, cercheremo un utente dicendo user.findone,
e poi so che nel jwt.payload,
c'è un campo ID che entra.
Quindi, questo è quello che sto per assegnare come campo ID qui.
Quindi, dirò, user.findone e il secondo
è una funzione di callback.
Come ti rendi conto, questo metodo utente Mongoose e si tenta di trovare.
Quindi, diremo se err allora, ritorno fatto.
Che cosa fa questo? Questo fatto è il callback che il
passaporto passerà nella vostra strategia qui.
Quindi, stiamo andando a chiamare questa funzione fatta.
Questo fatto in passaporto richiede tre parametri.
Quindi, puoi vedere le tre informazioni che questo fatto si aspetta che dica, errore: qualsiasi.
Quindi, se hai un errore lo passerai come primo parametro.
Il secondo parametro, utente? ,
Se esiste un utente,
il valore dell'utente verrà passato e quindi se qualche informazione? :, qualsiasi.
Quindi, questi due sono parametri opzionali e quindi,
se si passa in qualsiasi informazione,
allora che verrà utilizzato all'interno dell'applicazione.
Se passo false come secondo parametro,
significa che l'utente non esiste o quello.
Quindi, interpreterà che l'utente non esiste.
Quindi, potrei dire, err,
falso, perché questo è un errore.
Quindi, non ho intenzione di passare un valore utente lì,
ho solo intenzione di passare in false.
Lì, il prossimo,
possiamo dire, altrimenti se (utente).
Quindi, se l'utente non è nullo,
diremo return done (null).
Non c'è errore quindi, il primo parametro sarà
nullo e il secondo parametro è l'utente,
ma abbiamo appena ottenuto da MongoDB.
In caso contrario, torneremo
fatto con null, false.
Quindi, nell'ultimo caso,
non siamo riusciti a trovare l'utente,
quindi stiamo andando a passare in false.
Quindi, la gestiremo in questo modo.
Se vuoi, puoi creare un nuovo account utente a questo punto,
ma ho intenzione di mantenere questo semplice solo in modo che sia facile per noi capire.
Quindi, diremo solo, nullo, falso. Quello e' sei.
Quindi, questa è la strategia di passaporto JSONWebToken che ho appena configurato qui.
Inoltre, lasciami esportare
un'altra funzione da qui chiamata VerifyUser.
Ora, questa funzione VerifyUser,
lo userò per verificare un utente in arrivo.
Quindi, questo è dove userò passport.authenticate.
Quindi, il passport.authenticate, la strategia è la strategia jwt che ho appena configurato,
la strategia JsonWebToken che ho appena configurato.
Poi, la seconda parte,
direi, sessione: false.
Quindi, questo significa che,
non stiamo andando a creare sessioni in questo caso.
Come ricorderete, un'applicazione inversa,
stiamo usando l'autenticazione basata su token.
Quindi non creeremo sessioni.
Quindi, è per questo che ho impostato questa sessione
di opzione su false qui, e, naturalmente, il primo ha specificato la strategia che userò.
Quindi, per verificare un utente,
userò la strategia JWT.
Come funziona la strategia JWT?
Nella richiesta in arrivo,
il token verrà incluso nell'intestazione di autenticazione come abbiamo visto qui.
Abbiamo detto intestazione di autenticazione come token portatore.
Se questo è incluso, allora verrà estratto e che verrà
utilizzato per autenticare l'utente in base al token.
Correzione minore qui, questo dovrebbe essere user.findone_id è uguale a jwt_payload. _id,
perché questo è il valore id che si trova all'interno del payload del mio JSONWebToken.
Quindi, stiamo cercando l'utente con quel dato ID.
Quindi, una volta completato questo, ora,
la seconda parte che dobbiamo fare è che dobbiamo creare il token da qualche parte.
Ora, dove creiamo il token?
Quindi, questo è dove qualcosa che stiamo facendo nel file users.js è molto utile per noi.
Nel file users.js,
ricorda che hai già questo endpoint chiamato login.
Nell' endpoint di accesso
si utilizzava il nome utente e la password per autenticare l'utente.
Quindi, anche con JSONWebToken per emettere il JsonWebToken,
è necessario prima autenticare l'utente utilizzando una delle altre strategie,
e se si intende utilizzare prima la strategia locale,
autenticeremo l'utente utilizzando il nome utente e la password.
Una volta che l'utente è autenticato con il nome utente e
la password, allora emetteremo il token all'utente dicendo:
«Ok, sei un utente valido,
ti darò il token».
Tutte le richieste successive porteranno semplicemente il token
nell'intestazione del messaggio di richiesta in arrivo.
Quindi, prima, creavamo sessioni.
Quando l'utente è autenticato,
non useremo più le sessioni.
Invece, quando l'utente viene autenticato utilizzando la strategia locale,
emetteremo un token per l'utente.
Quindi, all'interno di questo metodo Router.post che abbiamo fatto su quell'endpoint /login,
ho intenzione di creare un token e passare questo token all'utente.
Quindi, qui, diremo un router.post.
Lasciatemi creare un token.
Per creare un token,
abbiamo questa funzione nel modulo di autenticazione chiamato Authenticate.getToken.
Quindi, ricordate, che abbiamo già,
per fare uso di questo, naturalmente,
anche prima di iniziare da lì,
ho bisogno di importare l'autenticazione.
Modulo qui. Quindi, diremo autenticare richiedono. /authenticate.
Quindi, quando nel tuo codice qui,
ora possiamo dire Authenticate.GetToken,
e il GetToken prende il parametro qui.
Ora, ricorda, tornando indietro il file authenticate.js.
Il file authenticate.js accetta qui un parametro
che verrà utilizzato come payload quando si crea il JSONWebToken.
Quindi, nel file users.js,
creerò un token dando un payload,
che contiene solo l'ID dell'utente.
Quindi, diremo id: req.user. _id
Questo è sufficiente per creare il JsonWebToken.
Non vogliamo includere altre informazioni dell'utente.
Se si sceglie di farlo, è possibile includere altre parti delle informazioni dell'utente,
ma suggerirei di mantenere piccolo JsonWebToken.
L' ID utente è sufficiente perché se è necessario cercare l'utente,
l'ID utente è sufficiente per cercare in MongoDB l'utente.
Quindi, ho intenzione di codificare solo l'ID dell'utente qui.
Ora, sai che req.user sarebbe già presente,
perché quando passport.authenticate ('local') autentica correttamente l'utente,
questo sta per caricare la proprietà utente sul messaggio di richiesta.
Quindi, è per questo che sono in grado di farlo qui.
Quindi, questo è ciò che userò per creare il token.
Ora, una volta creato il token,
voglio passare questo token all'utente.
Quindi, nell'oggetto rest.json che sto fornendo qui,
sto già portando il flag vero successo e anche,
un messaggio di stato qui.
Permettetemi di aggiungere il token
come una delle proprietà nel messaggio di risposta qui.
Quindi, il token che ho appena creato,
lo passerò come seconda proprietà all'interno di questa stringa Json qui.
Quindi ora, quando il mio client riceve questa stringa Json nel corpo del messaggio di risposta,
può entrare ed estrarre il token da lì.
Questo è tutto. Quindi, ora abbiamo aggiornato il file users.js
e ora puoi vedere come il token verrà
creato e inviato all'utente quando l'utente viene autenticato correttamente.
Ora, questo schema può essere utilizzato anche
quando si utilizza l'autenticazione di terze parti come basata su OAuth 2.0,
che esamineremo nel modulo successivo.
Ora, la procedura sarà simile.
Si creerà un token quando l'utente viene autenticato
dal provider di autenticazione di terze parti o OAuth
e quindi si passerà il token all'utente,
in un approccio simile a quello che si vede qui.
Ora, una volta che abbiamo fatto questo,
allora andiamo al file app.js.
Nel file app.js, perché abbiamo incluso un file di configurazione qui.
Quindi, lasciami richiedere il file di configurazione qui,
e poi l'URL che sto usando qui invece di hardcoding questo URL,
dirò config.mongoURL.
Quindi, ora, vedi come il mio file config.js può essere utilizzato come
luogo centralizzato in cui posso preparare la configurazione per la mia applicazione.
Questo è tutto. Quindi, ciò che accade ora è che quando l'utente si
autentica sull'endpoint /login e l'utente viene autenticato correttamente,
il token verrà creato dal server e restituito al client o all'utente.
Quindi, il client includerà il token in
ogni successiva richiesta in arrivo nell'intestazione di autorizzazione.
Ora, come include l'intestazione di autorizzazione?
Torniamo a authentic.js e qui,
si vede che abbiamo detto ExtractJWT.FromAuthHeaderErasBearerToken qui.
Quindi, questo sarà incluso nell'intestazione di autenticazione come token portatore.
Ti mostrerò come questo è fatto,
quindi usiamo il postino per includere il token portatore nell'intestazione di autenticazione.
Ora, quando questo arriva,
allora ricordi che proprio qui sotto,
hai configurato questo metodo qui chiamato VerifyUser,
che chiama l'autenticazione del passaporto con JWT.
Quindi, questo usa il token che
arriva nell'intestazione di autenticazione e quindi verifica l'utente.
Quindi, ogni volta che voglio verificare l'autenticità dell'utente,
posso semplicemente chiamare l'utente di verifica
e che avvierà la chiamata al passport.authenticate e verificherà lo sser.
Se questo ha successo
, mi permetterà di procedere.
Questa procedura è molto simile a quello che hai fatto nel
file users.js in cui richiami lo stesso passport.authenticate ('local').
Quindi, se questo ha successo,
allora vai avanti.
Se fallisce, la funzione di autenticazione restituirà il messaggio di errore
al client che dice che l'utente non è autorizzato.
Quindi, questo è già preso cura di.
Quindi ora, che abbiamo incluso questo nel mio file authenticate.js,
qualsiasi posto in cui voglio verificare l'utente,
posso semplicemente chiamare
questa funzione VerifyUser che
ho specificato qui o l'esportazione che ho specificato qui,
che chiameremo sul passport.authenticate usando
la strategia JWT per autenticare l'utente.
Ora, come facciamo a usarlo?
Ora, quello che faremo è andare in ognuno dei nostri router,
e controllare le opzioni su tutti i percorsi che vogliamo controllare.
Quindi, tornando al file app.js, ora,
che non stiamo usando sessioni ho intenzione di rimuovere questa sessione da qui,
perché non stiamo più usando le sessioni.
Allo stesso modo, ho intenzione di rimuovere questo passport.session da qui anche.
Anche questo non è necessario.
Inoltre, questa autenticazione, vedi prima,
quando ho configurato questa autenticazione,
questa autenticazione è stata applicata a ogni singola richiesta in entrata.
Ora, cambierò la mia applicazione,
per cui richiederò l'autenticazione solo su determinati percorsi e non su tutti i percorsi.
Quindi, lasciami rimuovere completamente questa autenticazione da app.js.
Quindi, ora, quando arriva la richiesta,
se è su/endpoint,
l'indice verrà servito.
Se si trova sull'endpoint /users, ti permetterà di passare
alle varie route che sono montate su/users nel users.js,
e successivamente, al resto di quelle.
Quello che farò ora è che lascerò
aperta la cartella pubblica affinché chiunque possa accedere.
Ora, in molte applicazioni,
questo potrebbe andare bene.
Quindi, lo lascio aperto.
Ora, sui piatti, sulle
promozioni e sull'endpoint dei leader,
tutte le richieste di ottenere.
Lascerò che vengano rispostati senza richiedere alcuna autenticazione.
Ora perche' dovrei volerlo fare?
Se un utente sta facendo una richiesta get,
l'utente vuole solo recuperare le informazioni.
Quindi, ad esempio, dal lato client se sto implementando un'applicazione web utilizzando Angular
o un'applicazione client che utilizza lo script ionico o nativo,
allora forse voglio implementare la mia app in
modo tale che la pagina principale
visualizzi già le informazioni genetiche che vuoi rendere disponibili a chiunque
visiti il tuo sito web o che apra la tua app.
Quindi, le informazioni di base possono essere visualizzate lì.
Ma se vuoi cambiare qualcosa,
ti aspetti che l'utente venga autenticato.
Quindi, consentirai operazioni POST, operazioni put
e operazioni di eliminazione solo da utenti autenticati.
Allo stesso modo, per i commenti, ad esempio,
si può dire che i commenti possono essere pubblicati o modificati solo da utenti autenticati.
Quindi, è possibile limitare solo alcuni percorsi per gli utenti autenticati,
l'altro percorso è possibile lasciarli aperti. Come facciamo?
Ora questo è dove l'utente di verifica che
abbiamo esportato dal file authenticate.js è utile.
Ora invece di controllare tutti i punti finali,
tutte le varie operazioni sui piatti, promozioni
e leader in punti,
apriremo solo le operazioni get per chiunque,
ma le
operazioni post, put ed delete saranno limitate solo agli utenti autenticati.
Nell' assegnazione, aggiungerai un'altra categoria di utenti denominati utenti admin.
Ora si dovrebbe limitare alcune operazioni per essere eseguite solo da utenti amministratori.
Quindi, ad esempio, la modifica dei piatti
o l'eliminazione delle informazioni dei piatti dal database,
sarà limitata solo agli utenti amministratori.
Ma gli utenti di base possono pubblicare commenti,
modificare i commenti che hanno pubblicato
e forse anche salvare alcuni piatti preferiti.
Faremo quella parte nel quarto modulo.
Ora, come controlliamo percorsi specifici?
Quindi questo è dove dobbiamo andare in ciascuno dei router
e quindi importare controlli su percorsi specifici.
Quindi, iniziamo con il percorso dei piatti.
Quindi, per il percorso dei piatti,
ricorderai che questo è controllato nel file dishRouter.js.
Quindi, andando a dishRouter.js,
cerchiamo prima di importare l'autenticazione qui.
Quindi diremo, const authenticate
richiedono../authenticate perché questo
file authenticator.js si trova nella cartella di livello superiore.
Quindi, ricorda../autentica qui.
Quindi, una volta importato l'autenticazione,
per il percorso del router piatto per questo percorso,
l'operazione get, ho intenzione di consentire senza alcun problema.
Quindi, questo è aperto.
Quindi non ho intenzione di imporre alcuna restrizione.
Dal post, se vogliamo applicare più middleware,
possiamo semplicemente aggiungere il principale all'interno di questo uno dietro l'altro.
Ora, quando viene chiamato il post, in questo
momento stai semplicemente eseguendo questa funzione qui.
Ora poco prima,
posso entrare e dire, Authenticate.VerifyUser, lì.
Allora, cosa fa questo?
Questo dice che se arriva una richiesta di post,
eseguirei prima questo middleware,
che ho esportato dal file authentic.js, per
prima cosa lo applico,
che equivale a dire passaporto autenticare JWT e stai controllando l'utente.
Quindi se questo ha successo,
allora passerò a fare il resto.
Se l'autenticazione non riesce a questo
punto, l'autenticazione passaporto
risponderà al client con il messaggio di errore appropriato.
Quindi questo è già gestito dall'autenticazione del passaporto,
quindi non devo preoccuparmi nulla oltre quel punto.
Se ho attraversato questo middleware e poi
eseguo la funzione successiva, significa che la mia autenticazione ha avuto successo,
quindi sono in grado di procedere in avanti da questo punto.
Quindi, questo agisce come la barriera per questo metodo post.
Ora usando lo stesso argomento,
posso semplicemente applicare questo particolare middleware a tutti gli altri metodi.
Posso farlo al put.
Anche se in questo caso,
mettere non sta andando a fare nulla.
Ma in ogni caso,
lo farò semplicemente per motivi di uniformità,
applicherò l'utente di verifica anche per mettere e, naturalmente,
anche per eliminare, ho intenzione di applicare put.
Allo stesso modo, scendendo su/dishId,
ottengo permetterò che funzioni senza alcun problema.
Post, applicherò l'utente di verifica.
Mettere anche applicherò l'utente di verifica e per eliminare anche lo stesso.
Per il/dishid/comments, lascerò il get open,
va bene per chiunque recuperare commenti su un piatto specifico.
Post, ho intenzione di chiudere questo,
quindi solo gli utenti verificati possono pubblicare commenti.
Metti anche io chiuderò questo e cancellerò troppo.
Devi fare un passo avanti e dire:
«Solo gli utenti che hanno pubblicato il commento possono eliminare i propri post.»
Ma lo faremo nel prossimo modulo.
Per il momento, ho intenzione di dire,
«Ok, un utente verificato può cancellare qualsiasi commento.»
Questo ovviamente non è vero,
possiamo mettere un ulteriore controllo,
ma lo faremo nel prossimo modulo di questo corso.
Quindi, per eliminare anche applico lo stesso.
Ancora una volta, per i commenti/commenti del router piatto Id,
ottenere lo lascerò aperto.
Post, lo lascio chiuso.
Metti anche chiudilo e poi per cancella anche chiuderò questo.
Elimina, naturalmente, come ho detto,
l'operazione di eliminazione dovrebbe essere consentita solo
a un utente che ha creato il commento dovrebbe essere chiesto di eliminarlo,
ma è necessario impostare alcune cose aggiuntive affinché funzioni correttamente, cosa
che faremo nel modulo successivo.
Per il momento, stiamo dicendo che un utente verificato può eliminare un commento specifico, il gioco è fatto.
Ora applicheremo lo stesso principio al router promozionale e anche al router leader.
Quindi, andando nel router promozionale,
lasciami importare l'autenticazione
e poi ottenere è aperto,
quindi questo è il router leader.
Quindi, ottenere è aperto.
Post, ho intenzione di controllare che,
mettere, controllare, eliminare, controllare,
leader router, leader ID,
get is okay, post,
controllato, put è controllato e delete è controllato.
Stessa cosa con il router promozionale.
Permettetemi di richiedere l'autenticazione
e quindi per il percorso get è aperto,
POST è controllato, put è controllato,
delete è controllato, stessa cosa per Promorouter/PromoID.
Get è aperto, POST è controllato,
put ed delete sono controllati anche, il gioco è fatto.
Salviamo tutte le modifiche.
Quindi, una volta completate tutte le modifiche,
salviamo le modifiche.
Ora, la nostra applicazione è pronta per essere testata.
Quindi, andiamo a riavviare il nostro server,
o se il server non è in esecuzione,
faremo solo avviare il server.
Andando al terminale,
il mio server non è in esecuzione.
Quindi, lasciami avviare il server digitando npm start.
È interessante notare che ha appena generato un errore qui,
volevo solo illustrarti che anche io posso commettere errori,
quindi vedrai che c'è un errore qui che dice
«Impossibile trovare module.authenticate», e poi se guardo attraverso il codice,
trovo che questo problema si è verificato in,
Dove si è verificato?
Quindi, cerco qui,
e poi da qualche parte quaggiù,
ho notato che questo problema si è verificato all'interno del mio file users.js.
Quindi, proprio lì, dice,
questo è nel file users.js.
Quindi, andando al file users.js, ripariamo questo.
Andando
al file users.js, proprio in alto quando ho richiesto l'autenticazione, ho detto,
«.authenticate», e come ti stavo
dicendo, dovrebbe essere un punto perché è nella cartella superiore.
Questo file users.js nella cartella Routes
e authenticate si trova nella cartella Projects Route quindi questo dovrebbe essere dot dot authenticate.
Quindi, se commetti degli errori,
ecco come ti verrà ricordato l'errore che hai introdotto.
Quindi, salviamo le modifiche e poi riavviamo il nostro server.
Ancora una volta, tornando a quel terminale,
lasciami avviare il mio server e il mio server è ora attivo e funzionante,
andiamo a Postman e poi testiamo la nostra applicazione.
Ora, in Postman, lasciami prima provare a fare
un GET su localhost: 3000/piatti e poi quando faccio un GET,
ha successo perché il punto finale GET non è controllato.
Così posso fare un GET sui piatti,
Posso fare un GET sulle promozioni,
e tutto funziona bene.
Ma se provo a fare un POST sui piatti,
quindi fammi trovare dove ho fatto un POST sui piatti.
Qui ho fatto un POST sui piatti.
Quindi, quando ho provato a fare un POST sui piatti,
dice immediatamente non autorizzato.
Quindi il mio modulo Passport si è reso conto che non sono autorizzato, quindi non mi è permesso farlo,
quindi è quello che mi sta ricordando.
Lasciami pulire i cookie da,
nel caso in cui trovi un cookie nel tuo Postman rimuovi semplicemente il cookie
corrispondente al localhost perché
quel cookie non è più necessario e non sarà richiesto.
Quindi, anche se rimuovo il cookie e poi POST,
dirà comunque non autorizzato.
Quindi, non sono autorizzato a fare queste operazioni.
Quindi, devo accedere.
Ora, se hai fatto l'esercizio precedente,
avresti lasciato l'utente a cui ti sei registrato in precedenza.
Quindi, ad esempio, avresti firmato questo particolare utente nell'esercizio precedente,
lasciami provare a registrare di nuovo lo stesso utente e il
mio server dovrebbe lamentarsi dicendo userExistsError in modo che significa che l'utente esiste,
quindi non ho bisogno di registrarmi di nuovo.
Se hai cancellato l'utente dal tuo MongoDB,
basta iscriverti quell'utente ancora una volta e poi facciamo il login.
Quindi, invieremo una richiesta di accesso a quel punto finale.
Quindi, quando invio la richiesta di accesso facendo un POST all'utente finale,
nota cosa viene restituito dal mio server.
Si nota immediatamente che nel messaggio di risposta
insieme al flag di successo e al messaggio di stato,
si ottiene anche un token qui.
Ora, questo particolare token,
ho bisogno di copiare questo token,
perché nelle mie richieste successive,
dovrò includere questo token.
Quindi, lasciami andare alla versione grezza di questo e che ho intenzione di copiare questo token.
Questo token non è altro che una lunga stringa lì,
quindi fammi copiare questo token.
Quindi ora se sei curioso di sapere cosa è contenuto in questo token,
il token Web JSON può essere esaminato.
C' è un particolare sito in cui puoi entrare e digitare
il tuo token Web JSON e quindi verificare effettivamente cosa c'è all'interno del token Web JSON.
Facciamolo come il prossimo passo.
In una finestra del browser,
basta digitare jwt.io e questo vi porterà a questo sito chiamato JSON Web Token jwt.io.
Se ricordi, nella lezione,
ti avevo mostrato la struttura del token Web JSON
e ti avevo mostrato che il token Web JSON contiene tre parti: l'intestazione,
il payload e le informazioni lì.
Ora, in questo caso,
le informazioni sono qui, quindi
incollerò il mio token Web JSON in questo lato sinistro,
quindi lasciami selezionarlo e quindi incollare
il mio token Web JSON nel lato sinistro nella parte codificata e poi sul lato destro,
ti sta mostrando esattamente ciò che è all'interno del token Web JSON che ho appena creato.
Quindi, dice che l'intestazione contiene queste due informazioni.
Il payload avviso che contiene l'ID
dell'utente e quindi la firma in basso qui.
Quindi, questo è ciò che è contenuto all'interno del mio token Web JSON.
Tornando al Postman,
fammi provare a prendere i piatti.
Quindi, quando dico GET localhost: 3000/piatti,
restituirà comunque una stringa
vuota, array vuoto qui perché il mio database non lo contiene.
Quindi, lasciami POST un piatto sul mio database.
Quindi, ho intenzione di scegliere l'operazione POST e nel corpo,
vedi che ho il mio piatto qui.
Nell' intestazione, ho intenzione di aggiungere la nuova intestazione chiamata
autorizzazione e si ricorda che in precedenza per l'autorizzazione di base,
hai detto di base e poi hai avuto la stringa codificata Base 64 lì.
Se si desidera includere il token Web JSON nell'intestazione di autorizzazione,
perché nel nostro codice,
abbiamo detto autorizzazione come token portatore.
Quindi, se si desidera includere il token nell'intestazione di autorizzazione,
nell'autorizzazione diremo portatore e poi incolleremo quella
stringa di token che abbiamo appena copiato dalla nostra richiesta in arrivo.
Quindi, incolleremo la stringa di token lì dentro.
Quindi, questo è ciò che sarà contenuto
nell'intestazione di autorizzazione della mia richiesta in uscita qui,
richiesta POST in uscita qui.
Quindi nota, il lato sinistro dice portatore e il lato destro è la stringa,
il token che ho appena copiato dal
punto in cui ho effettuato l'accesso e poi lasciami inviare il messaggio POST
ora e il mio POST ha successo e questo viene pubblicato nel mio database.
Ora, se vuoi essere sicuro che sia stato pubblicato,
facciamo un GET e quando fai un GET,
puoi vedere che effettivamente quel piatto è stato inserito nel mio database come mostrato qui.
Quindi, questo è il modo in cui userai i token Web JSON nella tua applicazione.
Quindi, ogni volta che è necessario eseguire un'
operazione POST, PUT o DELETE su uno qualsiasi degli endpoint,
si sta allegando.
Quindi, lasciami tornare a questa richiesta POST qui.
Nell' intestazione, inserirai
questo campo di autorizzazione e quindi questo verrebbe incluso nell'autorizzazione,
lo avvierai con il portatore e poi la stringa di token,
dopo quello spazio portatore,
un singolo spazio e poi la stringa di token che segue.
Quindi, ecco come i messaggi di richiesta
porterebbero il token Web JSON nell'intestazione del messaggio di richiesta in uscita.
È inoltre possibile includere il token nel corpo del messaggio di richiesta in uscita.
Ora, per questo, dovrai configurare
il tuo server express in particolare il JWT extra nel
file authenticate.js per accettarlo
dal corpo in modo da ricordare che lì abbiamo visto che
il JWT extra supporta molti modi diversi di estrarre
il token Web JSON dall' richiesta.
Quindi, lì è necessario specificare,
se hai intenzione di includerlo nel corpo,
è necessario specificare tali informazioni lì.
Ora, i dettagli su come farlo è possibile consultare
la documentazione del modulo Passport JWT per capire come questo è fatto.
In questo corso, ho intenzione di usarlo semplicemente nell'intestazione di autorizzazione
come ho mostrato qui e questo funziona bene per la maggior parte dei casi.
Ora, se si sta sviluppando un'app Web,
un'app angolare o un'app Ionic o NativeScript,
è necessario essere in grado di configurare
tale app in cui il token Web JSON verrà incluso nell'intestazione di autorizzazione.
Nell' ultima lezione di questo corso,
vi mostrerò come integrare il client e il server,
il client che avete sviluppato nei corsi precedenti con
il server che abbiamo sviluppato in questo corso.
Con questo, completiamo questo esercizio.
In questo esercizio, abbiamo visto come
possiamo configurare la nostra applicazione per utilizzare JSON Web Tokens,
e abbiamo visto come gestiamo l'autenticazione dell'utente utilizzando il token Web JSON,
utilizzando il supporto dal modulo Passport e il modulo Passport JWT,
e i moduli JSON Web Token Node.
Con questo, completiamo questo esercizio.
Questo è un buon momento per fare un Git Commit con il messaggio Passport JWT.