1
00:00:00,000 --> 00:00:04,746
[MUSICA]

2
00:00:04,746 --> 00:00:08,050
Parliamo in qualche linguaggio CORS ora.

3
00:00:08,050 --> 00:00:11,500
Ora che cosa è esattamente la condivisione dei risultati di origine incrociata, e

4
00:00:11,500 --> 00:00:15,325
perché è rilevante quando guardiamo le applicazioni web e

5
00:00:15,325 --> 00:00:21,010
le applicazioni hyper-mobile come abbiamo fatto in questa specializzazione?

6
00:00:21,010 --> 00:00:25,260
Come si capisce, la maggior parte delle pagine web ora estrae dati da

7
00:00:25,260 --> 00:00:29,790
molti siti diversi per costruire una pagina web.

8
00:00:29,790 --> 00:00:38,470
Ora, al fine di imporre una rigorosa politica di accesso alle risorse da siti diversi,

9
00:00:38,470 --> 00:00:44,220
la stessa politica di origine è stata imposta da molti browser.

10
00:00:44,220 --> 00:00:49,410
Ne parleremo un po 'di più in dettaglio nelle prossime diapositive, ma

11
00:00:49,410 --> 00:00:55,950
nel contesto dei framework di cui abbiamo discusso in questa particolare

12
00:00:55,950 --> 00:01:00,640
specializzazione, come Angular, Ionic e NativeScript,

13
00:01:00,640 --> 00:01:05,650
molti di questi coinvolgeranno script, codice JavaScript,

14
00:01:05,650 --> 00:01:11,220
che potrebbe essere necessario accedere alle risorse da siti diversi.

15
00:01:11,220 --> 00:01:16,790
Ed è qui che il problema CORS si presenta molto facilmente.

16
00:01:16,790 --> 00:01:22,290
Vediamo come affronteremo questo problema in modo più dettagliato in questa lezione e

17
00:01:22,290 --> 00:01:24,050
l'esercizio che segue.

18
00:01:25,940 --> 00:01:31,446
Ho brevemente accennato alla politica della stessa origine che ho iniziato questa lezione.

19
00:01:31,446 --> 00:01:36,510
Ora, il criterio della stessa origine è un modello di sicurezza delle app Web

20
00:01:36,510 --> 00:01:40,170
che limita il modo in cui un documento o

21
00:01:40,170 --> 00:01:45,380
uno script caricato da un'origine interagirà con le risorse di un'altra origine.

22
00:01:45,380 --> 00:01:50,270
Lo scopo di questo è quello di isolare documenti potenzialmente dannosi.

23
00:01:50,270 --> 00:01:54,940
Ora, ovviamente, quando hai una pagina web che coinvolge script,

24
00:01:54,940 --> 00:02:00,900
codice JavaScript, che potrebbe accedere alle risorse da un'altra posizione,

25
00:02:00,900 --> 00:02:05,185
codice potenzialmente dannoso potrebbe essere iniettato nella tua pagina web e

26
00:02:05,185 --> 00:02:12,800
per cui accedere a un'origine diversa da quella in cui si ottiene la tua pagina web.

27
00:02:12,800 --> 00:02:17,220
Ora, questa è la ragione per cui molti browser impongono questa politica della stessa origine.

28
00:02:17,220 --> 00:02:22,230
Ora, quando parliamo della stessa origine, come specifichiamo un'origine?

29
00:02:22,230 --> 00:02:28,540
Ora, in questo contesto, un'origine per qualsiasi risorsa è definita da tre tuple.

30
00:02:28,540 --> 00:02:32,980
Innanzitutto, il protocollo utilizzato per accedere alla risorsa.

31
00:02:32,980 --> 00:02:39,410
In secondo luogo, il nome host della risorsa o il dominio di tale risorsa.

32
00:02:39,410 --> 00:02:43,480
E in terzo luogo, il numero di porta in cui si accede a quella risorsa.

33
00:02:43,480 --> 00:02:48,700
Quindi questo è il modo in cui identifichiamo l'origine di qualsiasi risorsa. La

34
00:02:48,700 --> 00:02:53,626
risorsa in questo caso potrebbe essere una pagina html, un'immagine,

35
00:02:53,626 --> 00:03:00,720
i dati JSON ottenuti da un endpoint API REST e molti altri.

36
00:03:00,720 --> 00:03:05,410
Per approfondire ulteriormente la politica della stessa origine, diamo un'occhiata ad un esempio.

37
00:03:05,410 --> 00:03:12,315
Supponiamo di avere una pagina web che viene caricata da questo sito elencato qui,

38
00:03:12,315 --> 00:03:17,330
www.abc.com, e in una cartella xyz, e

39
00:03:17,330 --> 00:03:21,210
il page.html viene caricato qui.

40
00:03:21,210 --> 00:03:26,890
Questa pagina può includere collegamenti o anche codice JavaScript che potrebbe

41
00:03:26,890 --> 00:03:33,200
emettere XMLHttpRequest ad altre risorse sulla pagina web.

42
00:03:33,200 --> 00:03:38,310
Ora, in questo caso, se proviamo ad accedere ad un altro URL

43
00:03:38,310 --> 00:03:42,690
, ad esempio, il primo elencato qui, che ovviamente vedi

44
00:03:42,690 --> 00:03:47,860
proviene dallo stesso sito ma da una cartella diversa.

45
00:03:47,860 --> 00:03:51,820
Questo è accettabile, perché l'origine, in questo caso,

46
00:03:51,820 --> 00:03:55,420
il protocollo utilizzato e il numero di porta, rimane la stessa.

47
00:03:55,420 --> 00:04:00,660
Quindi, questo è accettabile per accedere a questa risorsa.

48
00:04:00,660 --> 00:04:05,470
Allo stesso modo, nel secondo caso, potremmo avere sotto

49
00:04:07,040 --> 00:04:10,570
diversi livelli di sottocartelle una risorsa a cui si accede.

50
00:04:10,570 --> 00:04:15,850
Ma ancora una volta, poiché la loro origine rimane la stessa, il che è accettabile.

51
00:04:15,850 --> 00:04:18,260
Ma diamo un'occhiata al terzo esempio qui.

52
00:04:18,260 --> 00:04:23,930
In questo esempio, vediamo che stiamo cercando di accedere a una risorsa qui con

53
00:04:23,930 --> 00:04:31,230
il protocollo https, che ovviamente viola l'entità stessa origine

54
00:04:31,230 --> 00:04:35,580
perché stiamo usando un protocollo diverso per accedere a quella risorsa a questo punto.

55
00:04:35,580 --> 00:04:39,030
Quindi questo sarebbe considerato un fallimento in questo caso.

56
00:04:39,030 --> 00:04:44,840
Il quarto caso è dove stiamo accedendo a una risorsa con un numero di porta diverso.

57
00:04:44,840 --> 00:04:50,300
E il quinto caso è dove stiamo accedendo a una risorsa in un altro host.

58
00:04:50,300 --> 00:04:54,830
Ora, tutti questi tre sarebbero contrassegnati come non validi o non

59
00:04:54,830 --> 00:04:58,110
è possibile accedere ai sensi della stessa politica di origine.

60
00:04:58,110 --> 00:05:02,710
Quindi, se si impone la politica della stessa origine per l'accesso da, ad esempio,

61
00:05:02,710 --> 00:05:10,970
XMLHttpRequest, in questo caso gli ultimi tre non sarebbero consentiti.

62
00:05:10,970 --> 00:05:16,270
Ma, naturalmente, ci sono molte situazioni in cui quel designer di siti

63
00:05:16,270 --> 00:05:22,510
può effettivamente ospitare risorse su siti diversi, forse su domini diversi,

64
00:05:22,510 --> 00:05:27,128
ed essere ancora in grado di estrarre i dati per costruire la pagina web o

65
00:05:27,128 --> 00:05:32,120
per far funzionare l'applicazione web o per eseguire l'applicazione mobile ibrida .

66
00:05:32,120 --> 00:05:38,914
Quindi, per soddisfare queste situazioni, la

67
00:05:38,914 --> 00:05:44,798
gestione delle richieste di origine incrociata è un metodo che ci permette di accedere a queste risorse.

68
00:05:44,798 --> 00:05:50,410
Quindi consideriamo una richiesta come una

69
00:05:50,410 --> 00:05:56,290
richiesta di origine incrociata se si sta tentando di accedere a una risorsa da un dominio diverso,

70
00:05:56,290 --> 00:06:01,240
o a un numero di porta diverso, o con un protocollo diverso.

71
00:06:01,240 --> 00:06:06,920
Quindi, come possiamo accogliere situazioni in cui si tratta di un accesso legittimo a una risorsa,

72
00:06:06,920 --> 00:06:08,800
ma a causa della politica della stessa origine,

73
00:06:08,800 --> 00:06:12,930
il tuo browser si rifiuterà di caricare questa risorsa?

74
00:06:12,930 --> 00:06:15,790
Ora è qui che, come ho detto,

75
00:06:15,790 --> 00:06:20,220
molti browser limiteranno le richieste http di origine incrociata,

76
00:06:20,220 --> 00:06:26,420
specialmente quelle avviate da XMLHttpRequest o dal

77
00:06:26,420 --> 00:06:30,570
protocollo Fetch per il recupero dei dati.

78
00:06:30,570 --> 00:06:36,980
Questi sono rilevanti quando accediamo a questi dall'interno del nostro codice JavaScript.

79
00:06:36,980 --> 00:06:41,950
Pertanto, in tali circostanze, ha senso imporre la politica della stessa origine,

80
00:06:41,950 --> 00:06:46,490
ma in tal caso dovremmo trovare un modo per aggirare la situazione in cui è

81
00:06:46,490 --> 00:06:49,980
possibile formulare una richiesta legittima.

82
00:06:49,980 --> 00:06:52,184
Questo è il punto in cui l'approccio CORS,

83
00:06:52,184 --> 00:06:56,960
l'approccio di condivisione delle risorse tra origini, viene in nostro aiuto.

84
00:06:56,960 --> 00:07:02,021
Quindi questo CORS è un meccanismo che consente ai server Web di eseguire richieste

85
00:07:02,021 --> 00:07:06,741
tra domini o richieste di origine incrociata.

86
00:07:06,741 --> 00:07:10,400
Quindi qui il browser e il server

87
00:07:10,400 --> 00:07:14,375
da cui stai cercando di riparare la risorsa interagiranno tra loro e

88
00:07:14,375 --> 00:07:20,945
poi giungeranno a un accordo dicendo che questo accesso è accettabile e consentito.

89
00:07:20,945 --> 00:07:23,575
Quindi, una volta raggiunto l'accordo,

90
00:07:23,575 --> 00:07:29,182
questa richiesta può essere consentita dal tuo browser.

91
00:07:29,182 --> 00:07:32,912
Quindi il browser e il server interagiranno tra loro per

92
00:07:32,912 --> 00:07:38,252
determinare se questo accesso a questa risorsa è una situazione accettabile.

93
00:07:38,252 --> 00:07:43,672
Quindi questo è dove un nuovo set di intestazioni HTTP è stato

94
00:07:43,672 --> 00:07:49,010
introdotto nei messaggi di risposta HTTP provenienti dal lato server.

95
00:07:49,010 --> 00:07:54,580
Queste intestazioni consentono ai server di descrivere l'insieme di origini

96
00:07:54,580 --> 00:08:01,690
a cui il server può accedere dal browser.

97
00:08:01,690 --> 00:08:06,760
E a sua volta il browser si rende conto che questi accessi

98
00:08:06,760 --> 00:08:11,405
alle risorse sono accettabili per essere consentiti, anche se stanno violando quella

99
00:08:11,405 --> 00:08:16,230
politica della stessa origine che abbiamo visto in precedenza.

100
00:08:16,230 --> 00:08:19,876
Quindi, in questo caso, abbiamo intestazioni come, ad esempio,

101
00:08:19,876 --> 00:08:24,821
Access-Control-Allow-Origin, Access-Control-Allow-Credenziali,

102
00:08:24,821 --> 00:08:29,780
Access-Control-Allow-Headers, Access-Control-Allow-Methods e

103
00:08:29,780 --> 00:08:35,330
alcuni altri che il server utilizza per informare il browser, dicendo che

104
00:08:35,330 --> 00:08:41,190
questo è un modo accettabile di accedere la risorsa dal lato del browser.

105
00:08:41,190 --> 00:08:46,970
E quando il browser vede questi messaggi di risposta in arrivo dal lato server,

106
00:08:46,970 --> 00:08:52,510
il browser accetta e consente di eseguire questa richiesta cross-origin.

107
00:08:52,510 --> 00:08:56,500
Ora, questo significa anche che il server dovrebbe essere impostato per essere in grado di

108
00:08:56,500 --> 00:09:01,230
rispondere con questi campi di intestazione e

109
00:09:01,230 --> 00:09:06,800
le informazioni di intestazione incluse nel messaggio di risposta provenienti dal lato server.

110
00:09:06,800 --> 00:09:11,424
Ora, questo è dove dividiamo tutte le richieste di origine incrociata in

111
00:09:11,424 --> 00:09:13,260
diverse categorie.

112
00:09:13,260 --> 00:09:18,495
Abbiamo il primo è la semplice richiesta cross-site.

113
00:09:18,495 --> 00:09:22,780
Nelle semplici richieste cross-site, potresti utilizzare GET o

114
00:09:22,780 --> 00:09:25,410
POST con il corpo della richiesta.

115
00:09:25,410 --> 00:09:30,180
Ma quando si utilizza il POST, il corpo della richiesta dovrebbe contenere

116
00:09:30,180 --> 00:09:34,688
Application/X-WWW-URLENcoded,

117
00:09:34,688 --> 00:09:39,305
o multipart/form-data, o text/plain.

118
00:09:39,305 --> 00:09:44,805
Quindi viene trattato come una semplice richiesta cross-site e

119
00:09:44,805 --> 00:09:47,625
in questo caso non saranno consentite intestazioni personalizzate.

120
00:09:47,625 --> 00:09:52,955
Quindi, in questo caso, è accettabile che il server informi il client,

121
00:09:52,955 --> 00:09:57,520
dicendo che questo è consentito e il browser dovrebbe consentire tali richieste.

122
00:09:57,520 --> 00:10:01,700
Quindi, ad esempio, per le risorse ampiamente accessibili, come, ad esempio,

123
00:10:01,700 --> 00:10:05,830
se si esegue una richiesta GET a un server per recuperare i dati per

124
00:10:05,830 --> 00:10:10,580
costruire l'interfaccia utente, allora forse la richiesta GET è accettabile

125
00:10:10,580 --> 00:10:14,400
indipendentemente dall'origine da cui proviene la richiesta.

126
00:10:14,400 --> 00:10:17,350
Quindi, in tal caso, il tuo server risponderà al client,

127
00:10:17,350 --> 00:10:23,250
dicendo Access-Conrol-Allow-Origin, con quella stella jolly qui, il

128
00:10:23,250 --> 00:10:27,830
che significa che qualsiasi origine che ha origine la richiesta è accettabile, e

129
00:10:27,830 --> 00:10:33,540
il browser dovrebbe consentire che la richiesta venga eseguita a quel server.

130
00:10:33,540 --> 00:10:38,020
E ora, puoi anche limitare l'accesso all'origine.

131
00:10:38,020 --> 00:10:44,440
In questo caso, puoi dire specificamente che se l'origine è

132
00:10:44,440 --> 00:10:50,090
un particolare sito, allora è accettabile soddisfare questa richiesta.

133
00:10:50,090 --> 00:10:55,940
Quindi il browser vede che l'invio di richieste

134
00:10:55,940 --> 00:11:01,230
con questo particolare sito di origine nella richiesta è accettabile e

135
00:11:01,230 --> 00:11:03,830
consentiremo la richiesta di origine incrociata.

136
00:11:03,830 --> 00:11:08,790
Quindi è possibile controllare il modo in cui l'origine è

137
00:11:08,790 --> 00:11:12,870
specificata nel messaggio di richiesta proveniente dal lato client.

138
00:11:12,870 --> 00:11:17,500
Quindi il server è in grado di accettare tali richieste.

139
00:11:17,500 --> 00:11:23,094
Alcune altre richieste rientrerebbero nella categoria delle richieste preflighed.

140
00:11:23,094 --> 00:11:27,750
Nella richiesta preflighed, ci si aspetta che prima che il client

141
00:11:27,750 --> 00:11:32,380
invii la richiesta effettiva, il client invierà una richiesta di verifica preliminare, il

142
00:11:32,380 --> 00:11:37,260
che significa che contatta il server per ottenere

143
00:11:37,260 --> 00:11:41,380
informazioni dal server prima che venga emessa la richiesta effettiva.

144
00:11:41,380 --> 00:11:46,580
Questo è il caso in cui si emettono richieste PUT e DELETE

145
00:11:46,580 --> 00:11:52,160
perché le richieste PUT e DELETE potrebbero causare modifiche sul lato server.

146
00:11:52,160 --> 00:11:58,100
E quindi qualsiasi metodo che causa effetti collaterali sui dati del server, come la

147
00:11:58,100 --> 00:12:03,538
richiesta PUT e DELETE, è appositamente richiesto di seguire l'approccio di verifica preliminare.

148
00:12:03,538 --> 00:12:08,276
Nell' approccio di verifica preliminare, l'idea è che il client

149
00:12:08,276 --> 00:12:12,919
invierà prima una richiesta OPTIONS HTTP sul lato server, e

150
00:12:12,919 --> 00:12:19,174
in risposta a quel messaggio di richiesta OPTIONS dal lato client, il server

151
00:12:19,174 --> 00:12:24,864
risponderà con i corrispondenti Access-Control-Allow-Headers,

152
00:12:24,864 --> 00:12:31,504
Access-Control-Allow-Origin, e le

153
00:12:31,504 --> 00:12:36,350
informazioni di intestazione Access-Control-Allow-Credentials nella risposta a un messaggio OPTIONS.

154
00:12:36,350 --> 00:12:42,359
Successivamente, il client deciderà se può emettere la richiesta di origine incrociata o

155
00:12:42,359 --> 00:12:48,870
meno in base alla risposta alla richiesta di verifica preliminare OPTIONS inviata dal client.

156
00:12:48,870 --> 00:12:53,410
Quindi questo è dove devi passare attraverso due passaggi prima che la tua richiesta

157
00:12:53,410 --> 00:12:57,205
possa essere consentita e gestita dal lato server.

158
00:12:58,340 --> 00:13:03,230
Una terza categoria di richieste CORS sarebbe quelle che vengono chiamate richieste con credenziali,

159
00:13:03,230 --> 00:13:07,900
in cui ci si aspetta che il client includa le credenziali nell'intestazione

160
00:13:07,900 --> 00:13:09,608
del messaggio di richiesta.

161
00:13:09,608 --> 00:13:13,518
Quindi le richieste che sono accompagnate da cookie, ad esempio, per

162
00:13:13,518 --> 00:13:19,040
riconoscere la sessione sul lato server, o qualche tipo di

163
00:13:19,040 --> 00:13:24,440
informazioni di autenticazione HTTP nell'intestazione di autorizzazione nel messaggio di richiesta.

164
00:13:24,440 --> 00:13:27,843
Quindi, in questo caso, il server deve rispondere con

165
00:13:27,843 --> 00:13:32,460
Access-Control-Allow-Credenziali: true sul lato client.

166
00:13:32,460 --> 00:13:37,920
Quindi, in questo caso, il server risponderà con questo e

167
00:13:37,920 --> 00:13:41,070
quindi il client sarà autorizzato a inviare le

168
00:13:41,070 --> 00:13:45,720
informazioni sulle credenziali nella richiesta in arrivo dal lato client.

169
00:13:45,720 --> 00:13:50,430
Ora, in questo caso, l'Access-Control-Allow-Origin non può

170
00:13:50,430 --> 00:13:56,550
avere il carattere jolly, la stella, nel messaggio di risposta.

171
00:13:56,550 --> 00:14:00,770
Si prevede di specificare esplicitamente l'origine a

172
00:14:00,770 --> 00:14:03,450
cui la richiesta può essere avviata.

173
00:14:04,500 --> 00:14:08,235
Ora, ovviamente, possiamo implementare gran parte del lavoro,

174
00:14:08,235 --> 00:14:13,796
cosa dobbiamo fare sul lato server, implementando il nostro middleware se così

175
00:14:13,796 --> 00:14:19,260
scegliamo di gestire le risposte correlate al CORS dal lato server.

176
00:14:19,260 --> 00:14:23,570
È molto semplice, come abbiamo visto nel codice che abbiamo implementato.

177
00:14:23,570 --> 00:14:29,140
Ovviamente, questo è un modo per gestire le risposte correlate a CORS dal lato server,

178
00:14:29,140 --> 00:14:34,800
ma fortunatamente, abbiamo uno specifico NoDeModule

179
00:14:34,800 --> 00:14:40,470
CORS progettato per gestire questo tipo di

180
00:14:40,470 --> 00:14:44,920
lavoro che il server deve fare per soddisfare i requisiti CORS.

181
00:14:44,920 --> 00:14:50,790
Quindi il NODEMOdule CORS ci consente di configurare il CORS sul lato server,

182
00:14:50,790 --> 00:14:55,810
specificando le informazioni

183
00:14:55,810 --> 00:15:01,010
di origine in cui sarebbero accettate le credenziali e molte altre informazioni in modo tale che è possibile configurare il server

184
00:15:01,010 --> 00:15:05,630
per essere in grado di gestire le risposte correlate CORS che deve fornire

185
00:15:05,630 --> 00:15:09,480
al browser in risposta al messaggio di richiesta.

186
00:15:09,480 --> 00:15:15,750
Per installare il nodo CORS, ovviamente vedi npm install cors

187
00:15:15,750 --> 00:15:22,280
e quindi configura il middleware CORS all'interno dell'applicazione Express.

188
00:15:23,430 --> 00:15:28,940
Il modulo CORS stesso fornisce un modo molto semplice per abilitare CORS.

189
00:15:28,940 --> 00:15:35,970
Puoi semplicemente includere l'app use CORS con parentesi vuote, e

190
00:15:35,970 --> 00:15:41,370
questo significa essenzialmente che stai aprendo il tuo server e risponderà con

191
00:15:41,370 --> 00:15:47,180
Access-Control-Allow-Origin con la stella jolly a ogni richiesta in arrivo.

192
00:15:47,180 --> 00:15:51,940
Ma quando stai configurando il tuo server, potresti volere un maggiore controllo su questo, quindi

193
00:15:51,940 --> 00:15:57,190
è qui che possiamo specificare opzioni aggiuntive per il CORS.

194
00:15:57,190 --> 00:16:02,790
E non solo, è possibile imporre la gestione CORS

195
00:16:02,790 --> 00:16:06,810
in modo diverso per percorsi diversi all'interno del lato server.

196
00:16:06,810 --> 00:16:12,320
Quindi, come vedremo nell'esercizio, imporremo diversi requisiti CORS sui

197
00:16:12,320 --> 00:16:17,540
diversi percorsi sul nostro lato server, e questo è tutto configurato utilizzando

198
00:16:17,540 --> 00:16:22,690
varie opzioni di configurazione che il NODEMOdule CORS supporta per noi.

199
00:16:22,690 --> 00:16:28,620
Quindi, utilizzando CORS NodeModule, è molto facile configurare il server per gestire

200
00:16:28,620 --> 00:16:34,020
qualsiasi richiesta di origine incrociata proveniente dal lato client e

201
00:16:34,020 --> 00:16:39,730
quindi rispondere con informazioni di intestazione appropriate sul lato client

202
00:16:39,730 --> 00:16:45,310
con intestazioni CORS appropriate nel messaggio di risposta dal lato server.

203
00:16:45,310 --> 00:16:48,450
Con questa rapida comprensione di CORS,

204
00:16:48,450 --> 00:16:54,730
sono sicuro che hai più domande a questo punto che risposte da questa lezione.

205
00:16:54,730 --> 00:16:58,960
Ma se vuoi leggere molti più dettagli su CORS,

206
00:16:58,960 --> 00:17:04,050
ti ho fornito risorse aggiuntive alla fine di questa lezione,

207
00:17:04,050 --> 00:17:06,804
che ti permettono di leggere di più su CORS stesso.

208
00:17:06,804 --> 00:17:11,553
Ma dal punto di vista di questo corso, vorremmo configurare la nostra

209
00:17:11,553 --> 00:17:15,037
applicazione espressa che abbiamo sviluppato

210
00:17:15,037 --> 00:17:19,150
finora per gestire le questioni relative ai CORS sul lato server.

211
00:17:19,150 --> 00:17:24,941
Quindi, passando all'esercizio, installeremo il modulo CORS npm e

212
00:17:24,941 --> 00:17:30,236
lo configureremo su vari percorsi all'interno del nostro server extra.

213
00:17:30,236 --> 00:17:33,629
[ MUSIC]