[MUSIC]
Nella lezione precedente, abbiamo appreso l'autenticazione di base.
Abbiamo visto che nell'autenticazione di base il client dovrà continuare esplicitamente ad
aggiungere nel campo di autorizzazione contenente il nome utente e
la password per ogni richiesta che il client invia al lato server.
Ora va perfettamente bene per l'autenticazione semplice.
I cookie sono un altro meccanismo che viene fornito che consente
al server di essere in grado di aspettarsi
che il client memorizzi alcune informazioni sul lato client e includa tali informazioni esplicitamente in ogni richiesta in uscita.
Quindi, invece di includere il tuo nome utente e
la password codificati in base 64 come abbiamo fatto nell'autenticazione
di base, usando i cookie, il tuo server potrebbe impostare un'informazione esplicita sul lato client
che verrà quindi inclusa in ogni richiesta in uscita dal lato client.
Ora espandendo ulteriormente questo, se il tuo server desidera tenere traccia delle informazioni sul tuo
client, allora il server potrebbe impostare esplicitamente un meccanismo di tracciamento della sessione.
Ora, i cookie sono piccoli e non possono memorizzare molte informazioni lì,
e questo ovviamente non può essere incluso nella richiesta in uscita.
I cookie possono includere alcune informazioni di base
nell'intestazione della richiesta in uscita dal client.
Ora, se vogliamo che molte più informazioni siano tracciate su un client
sul lato server, allora le sessioni espresse ci permettono di farlo.
Studiamo di più sui cookie e
le sessioni Express in modo più dettagliato in questa lezione ed
esploriamo ulteriormente negli esercizi che seguono questa lezione.
Quindi quali sono i cookie HTTP?
I cookie HTTP, come ho detto, sono piccoli pezzi di dati inviati
da un server web e memorizzati sul lato client.
Ora, quasi tutti i browser hanno la possibilità di supportare
la memorizzazione dei cookie sul lato client e includerli automaticamente
nella richiesta quando la richiesta viene inviata a un server specifico.
Quindi ogni richiesta successiva dal
lato client includerà una nuova intestazione lì
con il cookie nell'intestazione della richiesta.
Ora, ovviamente, se avete visto che la stampa popolare ha ottenuto una cattiva reputazione
lì, questo, ovviamente, non è del tutto immeritato.
Ma è saltato fuori misura rispetto a ciò che è veramente la verità.
Quindi prendi tutto quello che leggi sulla stampa popolare sui biscotti e
la loro cattiva reputazione con un chicco di sale.
I cookie sono molto utili per fare un sacco di cose interessanti.
E possiamo garantire che i cookie possano avere un'integrità sufficiente
incorporata in modo che non possano essere manipolati da nessuno nel mezzo.
Ora come funziona questa inclusione delle impostazioni dei cookie nella richiesta in uscita?
Quando un client invia una richiesta al sito server,
se il client è autenticato nel sito server.
Ad esempio, utilizzando l'autenticazione di base,
quindi il server può in cambio, impostare un cookie.
Ora, per impostare un cookie sul sito del client, il server includerà
nel messaggio di risposta un'intestazione con l'intestazione del cookie inviato e
il cookie effettivo nell'intestazione.
Ora, quando il client riceve il messaggio di risposta dal server contenente
l'intestazione Set-Cookie, allora imposterà il cookie sul lato client.
Tale che ogni richiesta successiva che va dal lato client
includerà esplicitamente un campo di intestazione chiamato come cookie e
intestazione effettiva che contiene come valore,
le informazioni sui cookie che sono state inviate dal server nel messaggio di risposta.
Quindi ogni messaggio di richiesta successivo porterà questo cookie nell'intestazione.
In tal modo, quando il server riceve questo messaggio di richiesta, è in grado di esaminare
il cookie e supporre da chi proviene questa richiesta.
Quindi è in grado di riconoscere il cliente guardando le informazioni sui cookie.
Quindi questo è dove i cookie si rivelano molto utili
per poter inviare informazioni di autorizzazione.
Quindi, nel servire includendo nome utente e password come parte dell'
intestazione di autenticazione di base in ogni richiesta in corso.
La prima volta che ti autentichi, invii il tuo nome utente e la tua password e
il server imposta il cookie dalla tua parte.
Successivamente, è sufficiente includere il cookie nella richiesta in uscita.
Ora i cookie possono anche avere una data di scadenza associata ad essi.
Quindi, a quel punto, il cookie sarà considerato scaduto e
non sarà più valido.
Quindi questo è un modo per controllare la durata per la
quale è valida un'autorizzazione.
Venendo su Express stesso, in che modo Express supporta i cookie?
Ora, come abbiamo capito, Express usa un sacco di middleware.
Questo è dove uno dei middleware che arriva chiamato il parser cookie
arriva alla nostra app alle otto.
Il parser di cookie consente al server di impostare un cookie nell'intestazione della risposta.
Quindi questo viene fatto utilizzando res.cookie e il nome e
alcuni valori e le opzioni come vedremo nell'esercizio successivo.
E così i cookie, quando vengono inviati dal lato client, inclusi in quel
messaggio di richiesta vengono analizzati sul lato server Express, utilizzando il parser di cookie.
Il middleware di cookie-parser,
che una volta installato ti consentirà di analizzare i cookie in arrivo.
E poi questi cookie in arrivo verranno aggiunti
nella richiesta come intestazione e possono essere esaminati sul lato server.
Ora, al fine di proteggere l'autenticità del cookie,
i cookie stessi possono essere firmati dal server.
Ora, quando il server firma un cookie, il server utilizza una chiave segreta,
che è nota solo al lato server.
Ora, se sai qualcosa di sicurezza informatica
, crittografia e crittografia, allora capisci cosa
significano firma e chiavi segrete e chiavi pubbliche e tutte queste cose.
Se non lo fai, basta dire che una chiave segreta è
una stringa specifica che solo il server conosce e nessun altro lo sa.
Quindi, quando un server crittografa un cookie, utilizzerà una chiave segreta come firma e
creerà ciò che viene chiamato come codice di autenticazione del messaggio keyy-hash.
E include questo in quel cookie che viene inviato dal server al lato client.
Questo HMAC creato sul lato server può essere fatto solo
da quel server specifico conoscendo quella chiave segreta.
Ora, poiché il server è una risorsa protetta,
solo il server conoscerà la chiave segreta e quindi è molto facile verificare
quando un cookie firmato viene inviato dal lato client al lato server.
Quindi, quando il cookie firmato viene inviato dal lato client al lato server,
il cookie verrà impostato sul lato client, e
quindi tutte le richieste successive includeranno questo cookie firmato nel lato client.
Ora il middleware del parser cookie che abbiamo impostato con il nostro server Express
supporta già i cookie firmati.
Ora per questo, nel parser cookie, si fornirà anche la chiave segreta come
parametro per il parser cookie quando si imposta il middleware del parser cookie.
In tal modo, tutti i cookie saranno firmati in modo appropriato e poi inviati.
E quando il cookie viene analizzato sul lato server nel
messaggio di richiesta in arrivo, questo verrà aggiunto nel messaggio di richiesta come req.signedCookies.
E poi puoi avere un campo specifico che puoi controllare nel cookie firmato.
I cookie sono un modo molto utile per
il tuo cliente essere in grado di inviare informazioni per cui il tuo server riconosce il client.
Ma naturalmente, i cookie hanno dei limiti.
Sono di dimensioni fisse, quindi non possono codificare molte
informazioni sul client che il loro server può recuperare dal cookie.
Il cookie viene utilizzato per ricordare al server
quale client sta inviando la richiesta.
Ora, se si desidera avere un meccanismo più elaborato per tenere traccia delle informazioni su
un client, sul lato server è possibile impostare ciò che viene chiamato come sessioni.
Ora, le sessioni è un meccanismo generico che è disponibile con qualsiasi server.
In particolare, esamineremo Express stesso e
come Express supporta la gestione delle sessioni sul lato server.
Il modo in cui funziona è che la sessione utente è impostata sul lato server.
Quindi questa sessione stessa è una combinazione di un cookie e
un ID di sessione, e il lato server tiene traccia delle informazioni
associate a quell'ID di sessione, o indicizzate da quell'ID di sessione.
Le informazioni di sessione possono avere qualsiasi
quantità di informazioni tracciate sul lato server e indicizzate da quel cookie.
Quindi, quando un client invia una richiesta sul server, dall'interno del cookie
viene recuperato l'ID di sessione e che viene utilizzato come indice nel lato server.
Ad esempio,
se si utilizza un database lato server tale indice sarà l'indice primario in
quel particolare database lato server che tiene traccia delle sessioni.
E quindi, ulteriori informazioni su quella sessione possono essere recuperate e
utilizzate dal server al fine di prendere decisioni su come servire
la richiesta client in arrivo.
Ora, per impostazione predefinita, le sessioni sono memorizzate in memoria sul sito server.
Ora, ovviamente, ciò significa che se il tuo server viene riavviato, la tua memoria
verrà cancellata e quindi tutte le informazioni sulla sessione saranno sparite completamente.
Quindi, invece, molti server ricorderanno all'
utilizzo di una qualche forma di archiviazione permanente in cui vengono tracciate le informazioni di sessione.
Lo storage permanente sul lato server potrebbe essere fatto
attraverso una sorta di archiviazione di file.
O anche sfruttare il fatto che si dispone già di un database sul lato server e
di memorizzare le informazioni sulla sessione sul lato server.
Ad esempio, nel tuo MongoDB stesso.
Ora, nell'esercizio che segue, esamineremo l'uso di un archivio di file per il
monitoraggio delle informazioni di sessione sul lato server.
Un altro aspetto a cui è necessario prestare attenzione è il fatto che se
si dispone di un'implementazione di server distribuito per cui più
server agiscono come server per la manutenzione della richiesta.
Quindi il server di distribuzione dovrebbe essere in grado di accedere alle informazioni di sessione.
Ognuno di questi server dovrebbe essere in grado di accedere alle informazioni di sessione.
Quindi è necessario uno strumento di sessioni di distribuzione sul lato server,
per consentire di supportare più server replicati.
Soprattutto questo è utile quando stiamo cercando di garantire l'affidabilità
del funzionamento del server.
Ora di nuovo, non otterremo troppi dettagli su quelli in questo particolare
corso, ci baseremo sulla comprensione fondamentalmente come funzionano le sessioni Express.
Venendo specificamente a Express e
come la gestione delle sessioni è supportata in Express.
Express utilizza il middleware di sessione express che supporta
l'utilizzo di sessioni in un server Express.
Ora si installa il middleware delle sessioni express.
E nell'esercizio, userò FileStore
come un modo per memorizzare permanentemente le informazioni sulla sessione.
E così includeremo anche il modulo nodo session-file-store che
ci permette di utilizzare i file sul lato server per tenere traccia delle informazioni di sessione.
Vedremo i dettagli nell'esercizio che segue.
E poi una volta fatto che la sessione stessa sarà impostata con il nuovo
server express dichiarando il middleware qui come sessione che prende
un certo insieme di opzioni come parametro qui.
Le opzioni includono il nome della sessione, quindi daremo l'ID di sessione per
la sessione particolare.
E poi si fornirà anche il segreto, una chiave segreta che viene utilizzata per
codificare il cookie firmato che verrà inviato al lato client.
E poi anche ulteriori informazioni tra cui SaveUninitialized, che
sarà un flag che viene utilizzato e anche un flag di salvataggio che viene utilizzato.
Verranno esaminati alcuni dettagli di queste opzioni nella diapositiva successiva.
Quindi tutte queste opzioni sono specificate qui.
E se sei FileStore come la memoria permanente per le tue sessioni,
allora dichiareremo che anche nelle opzioni di sessione lì.
Quindi questo è il modo in cui avremmo impostato una sessione sul lato server espresso
utilizzando il Middleware sessione express.
E il Middleware di sessione express, quando il client invia queste informazioni,
questo verrà analizzato sul lato server e
ciò comporterà l'aggiunta di una proprietà chiamata sessione all'oggetto richiesta.
Quindi queste informazioni di sessione saranno accessibili nell'
oggetto richiesta come req.session.
Quindi la req.session porterà ulteriori informazioni su quella particolare sessione
per quel particolare client.
Ora, una volta che questa sessione, la richiesta in arrivo viene analizzata dal middleware della sessione,
la proprietà req.session verrà aggiunta all'
oggetto messaggio di richiesta in arrivo che utilizza esplicitamente.
Quindi, dopo che la sessione è stata analizzata, la proprietà della sessione diretta sarà disponibile e
possiamo esaminarlo anche per verificare quale client ha inviato questa richiesta.
Quando impostano il loro oggetto sessione sul sito server,
come abbiamo visto, siamo in grado di impostare varie opzioni per quel sito server.
Il cookie, le opzioni dal cookie ID di sessione e il valore predefinito per
il cookie saranno come mostrato qui, che è path: '/',
httpOnly: true, secure: false, maxAge: null.
Quindi questo sarà il valore predefinito del cookie che verrà memorizzato sul pacchetto
e inviato al lato del client come cookie firmato.
E questo sarebbe incluso in ogni richiesta in arrivo dal sito del cliente.
Quindi il genid è la funzione che genera l'ID di sessione.
L' impostazione predefinita è utilizzare l'UUID del server stesso come ID generale.
Quindi il flag di salvataggio, se è vero, costringe una sessione a essere salvata nuovamente
nell'archivio anche se non viene modificata dalla richiesta.
A volte la richiesta in arrivo può
contenere la necessità di modificare le informazioni di sessione sul lato server.
E quindi, se le informazioni sulla sessione vengono modificate, dovrà essere persistente.
In caso contrario, non è necessario persistere.
Ma se si imposta il flag di risalvataggio su true, anche se le informazioni sulla sessione
sul server non vengono modificate dalla richiesta client in arrivo, verrà comunque salvata nuovamente.
Il flag successivo che abbiamo esaminato era SaveUninitialized.
Se questo è vero, creerà una sessione appena creata senza alcuna modifica
da salvare dell'archivio sessioni.
Ora imposteremo questo su false per impostazione predefinita, il che significa che ci sarà solo
tenere traccia di quelle sessioni che sono autorizzati sul server.
Ora il segreto, come vediamo, è la chiave segreta che viene utilizzata per firmare il cookie,
e il negozio stesso specifica l'istanza di archivio sessione che viene utilizzata.
L' impostazione predefinita è utilizzare l'archivio in memoria.
È possibile specificare l'archivio file o l'archivio Mongo per
memorizzare le informazioni sulla sessione e così via.
Quindi, una volta specificate queste informazioni per il middleware di sessione espressa,
la sessione verrà configurata in modo appropriato e quindi verrà tracciata sul lato server.
Ogni richiesta client verrà quindi mappata alle informazioni di sessione
sul lato server quando la richiesta client viene analizzata dal middleware sessione express.
E il req.session verrà aggiunto nell'oggetto richiesta.
Con questa comprensione dei cookie e delle sessioni express, passiamo
all'esercizio in cui vedremo come utilizzeremo prima i cookie.
E poi vedremo come faremo uso di sessioni Express Express
all'interno della nostra applicazione API REST Express su cui abbiamo lavorato finora.
[ MUSIC]