[MUSICA]
Parliamo in qualche linguaggio CORS ora.
Ora che cosa è esattamente la condivisione dei risultati di origine incrociata, e
perché è rilevante quando guardiamo le applicazioni web e
le applicazioni hyper-mobile come abbiamo fatto in questa specializzazione?
Come si capisce, la maggior parte delle pagine web ora estrae dati da
molti siti diversi per costruire una pagina web.
Ora, al fine di imporre una rigorosa politica di accesso alle risorse da siti diversi,
la stessa politica di origine è stata imposta da molti browser.
Ne parleremo un po 'di più in dettaglio nelle prossime diapositive, ma
nel contesto dei framework di cui abbiamo discusso in questa particolare
specializzazione, come Angular, Ionic e NativeScript,
molti di questi coinvolgeranno script, codice JavaScript,
che potrebbe essere necessario accedere alle risorse da siti diversi.
Ed è qui che il problema CORS si presenta molto facilmente.
Vediamo come affronteremo questo problema in modo più dettagliato in questa lezione e
l'esercizio che segue.
Ho brevemente accennato alla politica della stessa origine che ho iniziato questa lezione.
Ora, il criterio della stessa origine è un modello di sicurezza delle app Web
che limita il modo in cui un documento o
uno script caricato da un'origine interagirà con le risorse di un'altra origine.
Lo scopo di questo è quello di isolare documenti potenzialmente dannosi.
Ora, ovviamente, quando hai una pagina web che coinvolge script,
codice JavaScript, che potrebbe accedere alle risorse da un'altra posizione,
codice potenzialmente dannoso potrebbe essere iniettato nella tua pagina web e
per cui accedere a un'origine diversa da quella in cui si ottiene la tua pagina web.
Ora, questa è la ragione per cui molti browser impongono questa politica della stessa origine.
Ora, quando parliamo della stessa origine, come specifichiamo un'origine?
Ora, in questo contesto, un'origine per qualsiasi risorsa è definita da tre tuple.
Innanzitutto, il protocollo utilizzato per accedere alla risorsa.
In secondo luogo, il nome host della risorsa o il dominio di tale risorsa.
E in terzo luogo, il numero di porta in cui si accede a quella risorsa.
Quindi questo è il modo in cui identifichiamo l'origine di qualsiasi risorsa. La
risorsa in questo caso potrebbe essere una pagina html, un'immagine,
i dati JSON ottenuti da un endpoint API REST e molti altri.
Per approfondire ulteriormente la politica della stessa origine, diamo un'occhiata ad un esempio.
Supponiamo di avere una pagina web che viene caricata da questo sito elencato qui,
www.abc.com, e in una cartella xyz, e
il page.html viene caricato qui.
Questa pagina può includere collegamenti o anche codice JavaScript che potrebbe
emettere XMLHttpRequest ad altre risorse sulla pagina web.
Ora, in questo caso, se proviamo ad accedere ad un altro URL
, ad esempio, il primo elencato qui, che ovviamente vedi
proviene dallo stesso sito ma da una cartella diversa.
Questo è accettabile, perché l'origine, in questo caso,
il protocollo utilizzato e il numero di porta, rimane la stessa.
Quindi, questo è accettabile per accedere a questa risorsa.
Allo stesso modo, nel secondo caso, potremmo avere sotto
diversi livelli di sottocartelle una risorsa a cui si accede.
Ma ancora una volta, poiché la loro origine rimane la stessa, il che è accettabile.
Ma diamo un'occhiata al terzo esempio qui.
In questo esempio, vediamo che stiamo cercando di accedere a una risorsa qui con
il protocollo https, che ovviamente viola l'entità stessa origine
perché stiamo usando un protocollo diverso per accedere a quella risorsa a questo punto.
Quindi questo sarebbe considerato un fallimento in questo caso.
Il quarto caso è dove stiamo accedendo a una risorsa con un numero di porta diverso.
E il quinto caso è dove stiamo accedendo a una risorsa in un altro host.
Ora, tutti questi tre sarebbero contrassegnati come non validi o non
è possibile accedere ai sensi della stessa politica di origine.
Quindi, se si impone la politica della stessa origine per l'accesso da, ad esempio,
XMLHttpRequest, in questo caso gli ultimi tre non sarebbero consentiti.
Ma, naturalmente, ci sono molte situazioni in cui quel designer di siti
può effettivamente ospitare risorse su siti diversi, forse su domini diversi,
ed essere ancora in grado di estrarre i dati per costruire la pagina web o
per far funzionare l'applicazione web o per eseguire l'applicazione mobile ibrida .
Quindi, per soddisfare queste situazioni, la
gestione delle richieste di origine incrociata è un metodo che ci permette di accedere a queste risorse.
Quindi consideriamo una richiesta come una
richiesta di origine incrociata se si sta tentando di accedere a una risorsa da un dominio diverso,
o a un numero di porta diverso, o con un protocollo diverso.
Quindi, come possiamo accogliere situazioni in cui si tratta di un accesso legittimo a una risorsa,
ma a causa della politica della stessa origine,
il tuo browser si rifiuterà di caricare questa risorsa?
Ora è qui che, come ho detto,
molti browser limiteranno le richieste http di origine incrociata,
specialmente quelle avviate da XMLHttpRequest o dal
protocollo Fetch per il recupero dei dati.
Questi sono rilevanti quando accediamo a questi dall'interno del nostro codice JavaScript.
Pertanto, in tali circostanze, ha senso imporre la politica della stessa origine,
ma in tal caso dovremmo trovare un modo per aggirare la situazione in cui è
possibile formulare una richiesta legittima.
Questo è il punto in cui l'approccio CORS,
l'approccio di condivisione delle risorse tra origini, viene in nostro aiuto.
Quindi questo CORS è un meccanismo che consente ai server Web di eseguire richieste
tra domini o richieste di origine incrociata.
Quindi qui il browser e il server
da cui stai cercando di riparare la risorsa interagiranno tra loro e
poi giungeranno a un accordo dicendo che questo accesso è accettabile e consentito.
Quindi, una volta raggiunto l'accordo,
questa richiesta può essere consentita dal tuo browser.
Quindi il browser e il server interagiranno tra loro per
determinare se questo accesso a questa risorsa è una situazione accettabile.
Quindi questo è dove un nuovo set di intestazioni HTTP è stato
introdotto nei messaggi di risposta HTTP provenienti dal lato server.
Queste intestazioni consentono ai server di descrivere l'insieme di origini
a cui il server può accedere dal browser.
E a sua volta il browser si rende conto che questi accessi
alle risorse sono accettabili per essere consentiti, anche se stanno violando quella
politica della stessa origine che abbiamo visto in precedenza.
Quindi, in questo caso, abbiamo intestazioni come, ad esempio,
Access-Control-Allow-Origin, Access-Control-Allow-Credenziali,
Access-Control-Allow-Headers, Access-Control-Allow-Methods e
alcuni altri che il server utilizza per informare il browser, dicendo che
questo è un modo accettabile di accedere la risorsa dal lato del browser.
E quando il browser vede questi messaggi di risposta in arrivo dal lato server,
il browser accetta e consente di eseguire questa richiesta cross-origin.
Ora, questo significa anche che il server dovrebbe essere impostato per essere in grado di
rispondere con questi campi di intestazione e
le informazioni di intestazione incluse nel messaggio di risposta provenienti dal lato server.
Ora, questo è dove dividiamo tutte le richieste di origine incrociata in
diverse categorie.
Abbiamo il primo è la semplice richiesta cross-site.
Nelle semplici richieste cross-site, potresti utilizzare GET o
POST con il corpo della richiesta.
Ma quando si utilizza il POST, il corpo della richiesta dovrebbe contenere
Application/X-WWW-URLENcoded,
o multipart/form-data, o text/plain.
Quindi viene trattato come una semplice richiesta cross-site e
in questo caso non saranno consentite intestazioni personalizzate.
Quindi, in questo caso, è accettabile che il server informi il client,
dicendo che questo è consentito e il browser dovrebbe consentire tali richieste.
Quindi, ad esempio, per le risorse ampiamente accessibili, come, ad esempio,
se si esegue una richiesta GET a un server per recuperare i dati per
costruire l'interfaccia utente, allora forse la richiesta GET è accettabile
indipendentemente dall'origine da cui proviene la richiesta.
Quindi, in tal caso, il tuo server risponderà al client,
dicendo Access-Conrol-Allow-Origin, con quella stella jolly qui, il
che significa che qualsiasi origine che ha origine la richiesta è accettabile, e
il browser dovrebbe consentire che la richiesta venga eseguita a quel server.
E ora, puoi anche limitare l'accesso all'origine.
In questo caso, puoi dire specificamente che se l'origine è
un particolare sito, allora è accettabile soddisfare questa richiesta.
Quindi il browser vede che l'invio di richieste
con questo particolare sito di origine nella richiesta è accettabile e
consentiremo la richiesta di origine incrociata.
Quindi è possibile controllare il modo in cui l'origine è
specificata nel messaggio di richiesta proveniente dal lato client.
Quindi il server è in grado di accettare tali richieste.
Alcune altre richieste rientrerebbero nella categoria delle richieste preflighed.
Nella richiesta preflighed, ci si aspetta che prima che il client
invii la richiesta effettiva, il client invierà una richiesta di verifica preliminare, il
che significa che contatta il server per ottenere
informazioni dal server prima che venga emessa la richiesta effettiva.
Questo è il caso in cui si emettono richieste PUT e DELETE
perché le richieste PUT e DELETE potrebbero causare modifiche sul lato server.
E quindi qualsiasi metodo che causa effetti collaterali sui dati del server, come la
richiesta PUT e DELETE, è appositamente richiesto di seguire l'approccio di verifica preliminare.
Nell' approccio di verifica preliminare, l'idea è che il client
invierà prima una richiesta OPTIONS HTTP sul lato server, e
in risposta a quel messaggio di richiesta OPTIONS dal lato client, il server
risponderà con i corrispondenti Access-Control-Allow-Headers,
Access-Control-Allow-Origin, e le
informazioni di intestazione Access-Control-Allow-Credentials nella risposta a un messaggio OPTIONS.
Successivamente, il client deciderà se può emettere la richiesta di origine incrociata o
meno in base alla risposta alla richiesta di verifica preliminare OPTIONS inviata dal client.
Quindi questo è dove devi passare attraverso due passaggi prima che la tua richiesta
possa essere consentita e gestita dal lato server.
Una terza categoria di richieste CORS sarebbe quelle che vengono chiamate richieste con credenziali,
in cui ci si aspetta che il client includa le credenziali nell'intestazione
del messaggio di richiesta.
Quindi le richieste che sono accompagnate da cookie, ad esempio, per
riconoscere la sessione sul lato server, o qualche tipo di
informazioni di autenticazione HTTP nell'intestazione di autorizzazione nel messaggio di richiesta.
Quindi, in questo caso, il server deve rispondere con
Access-Control-Allow-Credenziali: true sul lato client.
Quindi, in questo caso, il server risponderà con questo e
quindi il client sarà autorizzato a inviare le
informazioni sulle credenziali nella richiesta in arrivo dal lato client.
Ora, in questo caso, l'Access-Control-Allow-Origin non può
avere il carattere jolly, la stella, nel messaggio di risposta.
Si prevede di specificare esplicitamente l'origine a
cui la richiesta può essere avviata.
Ora, ovviamente, possiamo implementare gran parte del lavoro,
cosa dobbiamo fare sul lato server, implementando il nostro middleware se così
scegliamo di gestire le risposte correlate al CORS dal lato server.
È molto semplice, come abbiamo visto nel codice che abbiamo implementato.
Ovviamente, questo è un modo per gestire le risposte correlate a CORS dal lato server,
ma fortunatamente, abbiamo uno specifico NoDeModule
CORS progettato per gestire questo tipo di
lavoro che il server deve fare per soddisfare i requisiti CORS.
Quindi il NODEMOdule CORS ci consente di configurare il CORS sul lato server,
specificando le informazioni
di origine in cui sarebbero accettate le credenziali e molte altre informazioni in modo tale che è possibile configurare il server
per essere in grado di gestire le risposte correlate CORS che deve fornire
al browser in risposta al messaggio di richiesta.
Per installare il nodo CORS, ovviamente vedi npm install cors
e quindi configura il middleware CORS all'interno dell'applicazione Express.
Il modulo CORS stesso fornisce un modo molto semplice per abilitare CORS.
Puoi semplicemente includere l'app use CORS con parentesi vuote, e
questo significa essenzialmente che stai aprendo il tuo server e risponderà con
Access-Control-Allow-Origin con la stella jolly a ogni richiesta in arrivo.
Ma quando stai configurando il tuo server, potresti volere un maggiore controllo su questo, quindi
è qui che possiamo specificare opzioni aggiuntive per il CORS.
E non solo, è possibile imporre la gestione CORS
in modo diverso per percorsi diversi all'interno del lato server.
Quindi, come vedremo nell'esercizio, imporremo diversi requisiti CORS sui
diversi percorsi sul nostro lato server, e questo è tutto configurato utilizzando
varie opzioni di configurazione che il NODEMOdule CORS supporta per noi.
Quindi, utilizzando CORS NodeModule, è molto facile configurare il server per gestire
qualsiasi richiesta di origine incrociata proveniente dal lato client e
quindi rispondere con informazioni di intestazione appropriate sul lato client
con intestazioni CORS appropriate nel messaggio di risposta dal lato server.
Con questa rapida comprensione di CORS,
sono sicuro che hai più domande a questo punto che risposte da questa lezione.
Ma se vuoi leggere molti più dettagli su CORS,
ti ho fornito risorse aggiuntive alla fine di questa lezione,
che ti permettono di leggere di più su CORS stesso.
Ma dal punto di vista di questo corso, vorremmo configurare la nostra
applicazione espressa che abbiamo sviluppato
finora per gestire le questioni relative ai CORS sul lato server.
Quindi, passando all'esercizio, installeremo il modulo CORS npm e
lo configureremo su vari percorsi all'interno del nostro server extra.
[ MUSIC]