[MUSIC]
Il server API REST Express implementato nel
modulo precedente consente a qualsiasi utente di eseguire qualsiasi operazione GET o POST o DELETE.
Non vi è alcun controllo su chi può eseguire questa operazione.
Quindi, il che significa che,
se esegui un server come quello, chiunque può entrare nel tuo server e
iniziare a manipolare le informazioni che sono presenti all'interno del tuo database.
Questa è ovviamente una situazione pericolosa.
Il modo in cui il server dovrebbe essere implementato è che, è
necessario avere una sorta di restrizione su
quali tipi di utenti saranno autorizzati a eseguire quali tipi di operazioni.
Quindi forse, consentiresti a
un utente autorizzato solo di eseguire operazioni GET.
Quindi, per esempio, se vuoi che un ospite sia in grado di vedere
informazioni sui piatti nel tuo ristorante o
sul menu del tuo ristorante e così via, questo è perfettamente accettabile.
Tuttavia, è possibile consentire solo a un amministratore di entrare e
modificare le informazioni sul piatto o di eliminare un piatto dal menu.
E anche aggiornare un piatto esistente nel menu, o una promozione,
o le informazioni sui leader nel vostro lato server.
Ora, si potrebbe anche avere un altro gruppo di utenti che saranno registrati utenti
che possono essere autorizzati a salvare alcuni dei loro piatti come loro piatti preferiti,
e solo loro sarebbero in grado di manipolare l'elenco dei loro piatti preferiti.
Quindi questo è un altro livello di autorizzazione o
autenticazione che è necessario eseguire.
Quindi, hai diversi gradi di utenti e
anche, a seconda del tipo di operazioni che sarebbero autorizzati a eseguire.
Quindi tutto ciò significa che hai bisogno di un qualche tipo di sicurezza per essere
integrato nel tuo lato server.
Vedremo come possiamo autenticare gli utenti e
poi decidere che tipo di utente è questo client.
E poi, a seconda del tipo di utente,
è possibile consentire all'utente di eseguire determinati tipi di operazioni.
Inizieremo con la comprensione di base di questo, ciò che chiamiamo come
autenticazione di base in un lato server per
un client, e poi, costruire su questo in tutto il resto di questo modulo.
E poi alla fine di questo modulo, finiremo con un meccanismo
, consentendo così agli utenti di registrarsi.
Inoltre, gli utenti registrati possono eseguire determinate operazioni
che un utente non registrato non può e così via.
Quindi imporremo vari tipi di controlli di accesso per
varie operazioni sul lato server in base al tipo di utente.
Quindi questo ti imposta la prospettiva, o
meglio l'idea di ciò che incontrerai in questo modulo.
Iniziamo con l'autenticazione di base,
il meccanismo di base che ci permetterà di autenticare gli utenti.
L' autenticazione di base in HTTP è un meccanismo molto semplice,
che chiederà all'utente un nome utente e una
password da inviare con una richiesta.
E c'è una struttura specifica
su come queste informazioni verranno inviate dal client al lato server.
Quindi, questa è una questione, l'autenticazione di accesso di base, che HTTP supporta,
è una questione che consentirà a un server di sfidare un client e chiedere
il nome utente e la password da inviare dal client.
In questo modo il server può sfidare il client ad autenticarsi digitando queste
informazioni.
Il client deve inviare il nome utente e
la password in risposta alla sfida dal lato server.
Quindi, ogni messaggio di richiesta proveniente da un client
dovrebbe includere la forma codificata del nome utente e
della password nell'intestazione della richiesta che va dal client al lato server.
Quindi, quando il server riceve la richiesta,
il server estrarrà queste informazioni dall'intestazione della richiesta del client.
E poi, usalo per autenticare il client prima di
consentire l'accesso alle varie operazioni sul lato server.
Quindi, come funziona questa autenticazione?
Se un client invia una richiesta al server e
questa richiesta client non include la formazione dell'autorizzazione, il server
contesterà il client, sta chiedendo al client di inviare queste informazioni.
Il server sfida il client includendo
un'intestazione nel messaggio di risposta in arrivo.
L' intestazione con il tipo come WWW-Authenticate e
quindi la seconda parte in cui specifica il tipo è dove
specificherà il tipo di autenticazione che il client deve inviare.
E inizieremo con la comprensione dell'autenticazione di base qui.
E si noti anche che il messaggio di risposta conterrà un codice di errore 401,
che non è autorizzato, che significa non autorizzato.
Quindi, quando la risposta ritorna dal lato server, il client,
in risposta a questa risposta in arrivo, il client dovrà inviare la propria richiesta,
includendo un campo di intestazione specifico nel messaggio di richiesta del tipo di autorizzazione.
E questo campo di intestazione di autorizzazione conterrà alcune informazioni lì dentro.
Per un'autenticazione di base, queste informazioni sarebbero sotto forma di,
come la prima parola qui, sarà di base.
E poi seguito da uno spazio qui, e seguito da una stringa codificata Base64 qui.
Questa stringa codificata Base64 codifica il nome utente e
la password in un formato particolare, e quindi include che nell'intestazione.
Ora stai dicendo, se invii un messaggio di richiesta come questo,
incluso questo, nell'intestazione, allora chiunque nel mezzo.
Quindi, se sai qualcosa sulla sicurezza e su
come possono essere lanciati gli attacchi dell'uomo nel mezzo, allora ovviamente,
questo può essere recuperato da un intruso nel mezzo,
e poi può essere usato per fingere il vero cliente.
Ancora una volta, al momento non stiamo affrontando questa questione.
Quando parlo di HTTPS nel prossimo modulo,
tornerò per affrontare questo problema in modo un po 'più dettagliato.
Ma per il momento, le informazioni nell'intestazione verranno inviate
senza essere crittografate nell'intestazione in questo momento.
Ora, un altro motivo per cui lo sto facendo è che, in modo che possiamo effettivamente guardare
direttamente l'intestazione e quindi vedere queste informazioni nell'intestazione stessa.
Quindi, quando il client invia questa richiesta, il server estrarrà
le informazioni da questa intestazione di autorizzazione nell'intestazione della richiesta.
E quindi utilizzare queste informazioni per verificare se si tratta di
una richiesta client autorizzata o meno.
Ora, naturalmente, la tua prossima domanda sarebbe,
cosa contiene esattamente questa intestazione di autorizzazione?
L' intestazione di autorizzazione stessa è costruita come segue.
Se hai un nome utente e una password, queste sono le due
informazioni che userai per autenticare un client.
Quindi il nome utente e la password saranno concatenati in una singola stringa
dicendo nome utente e due punti, e la password stessa.
Quindi la stringa del nome utente, i due punti e
la password saranno concatenati insieme in un'intera stringa qui.
Questa stringa risultante che otteniamo qui è quella, codificata usando la codifica Base64.
Se sai come la codifica viene eseguita le basi per la codifica,
convertirlo in un'intestazione ASCII come mostrato in questo esempio qui,
quindi questa non è altro che una stringa di intestazioni ASCII.
Ora, se non sai molto sulla codifica rigida di base, non preoccuparti,
non influisce sulla tua comprensione di ciò che sta succedendo qui comunque.
Quindi questa stringa codificata Basic64, quindi
questa particolare informazione è codificata in una stringa come questa, e
quindi racchiusa nell'intestazione della richiesta che va dal client al server.
L' intestazione della richiesta stessa è dell'autorizzazione del tipo,
e quindi seguita dal valore effettivo qui, che dice,
Basic, e uno spazio qui, e la stringa codificata Base64 qui.
Quindi, quando questo viene ricevuto dal nostro server, il server estrarrà queste informazioni,
e poi da qui, estrarrà il nome utente e la password, e
quindi verificherà se corrisponde a un utente autorizzato o meno sul lato server.
Per aiutarti a capire meglio come organizziamo effettivamente l'applicazione espressa
e come viene eseguita l'autenticazione stessa, come abbiamo appreso in precedenza,
le stesse applicazioni express sono organizzate in un set di middleware.
E il modo in cui funziona l'applicazione espressa è che il middleware
viene applicato alla richiesta e al messaggio di risposta
nell'ordine in cui è dichiarato nella mia applicazione espressa.
Quindi, se hai un express.use e
poi hai il primo che dice un server statico, dopo di che,
hai un altro middleware, poi hai un altro middleware.
La sequenza in cui sono dichiarati nel file app.js dei server express,
ad esempio, è la sequenza esatta in cui verrà applicato il middleware.
Quindi una richiesta in arrivo dal lato server come si ricorda nell'
applicazione espressa, la richiesta in arrivo viene trattata come un oggetto di richiesta.
L' oggetto risposta è ciò che il server express costruisce, e
quindi il successivo è consente di passare al middleware successivo
che si sta per applicare, e così via.
Quindi, una richiesta in arrivo come questa, quando arriva, viene applicato il primo middleware.
E poi una volta che il middleware ha trasformato sia
la richiesta che la risposta, passa al middleware successivo, che viene quindi applicato ad esso.
Ad esempio, abbiamo visto che abbiamo applicato prima Morgan,
poi abbiamo applicato il parser del corpo al middleware.
Quindi devono aver già trasformato la richiesta e gli oggetti risposta.
E poi, dopo, possiamo includere un middleware di autenticazione in atto lì.
Il middleware di autenticazione autenticherà la richiesta.
Ora, quindi se si utilizza l'autenticazione di base, la richiesta
deve contenere nell'intestazione l'intestazione di autorizzazione in atto lì.
Quindi l'intestazione di autorizzazione verrà estratta dal middleware di autenticazione
e quindi controllata per vedere se l'utente è autorizzato.
E se il middleware di autenticazione rileva che sei un utente autorizzato,
allora ti sarà permesso di passare al set successivo di
middleware che segue il passaggio di autenticazione.
E i tuoi record saranno elaborati dal middleware successivo.
Ma d'altra parte,
se il middleware di autenticazione decide che non sei un utente autorizzato,
allora il middleware di autenticazione ti porterà lungo un percorso diverso.
Quindi generare un errore e quindi inviare
una risposta di errore appropriata a quel lato client e
verrà reindirizzato al gestore degli errori.
Quindi questo reindirizzamento al gestore di errori verrà eseguito chiamando Next
con l'errore come parametro a quello Next here.
Quindi il prossimo è esattamente questo Avanti che vediamo nella risorsa richiesta Avanti qui.
E così, questo ti porterà fino al gestore degli errori,
che gestirà l'errore e quindi restituirà il messaggio di errore sul lato client,
indicando il fallimento dell'autenticazione.
Quindi questo è il modo in cui la tua tipica autorizzazione
di base o autenticazione di base funziona nell'applicazione lato server.
Avendo capito questo, passiamo all'esercizio in cui
implementeremo l'autenticazione di base nella nostra applicazione e
vedere come autentica gli utenti.
[ MUSIC]