1
00:00:00,000 --> 00:00:04,470
[MUSIC]

2
00:00:04,470 --> 00:00:10,326
Il server API REST Express implementato nel

3
00:00:10,326 --> 00:00:17,750
modulo precedente consente a qualsiasi utente di eseguire qualsiasi operazione GET o POST o DELETE.

4
00:00:17,750 --> 00:00:21,360
Non vi è alcun controllo su chi può eseguire questa operazione.

5
00:00:21,360 --> 00:00:22,350
Quindi, il che significa che,

6
00:00:22,350 --> 00:00:27,180
se esegui un server come quello, chiunque può entrare nel tuo server e

7
00:00:27,180 --> 00:00:33,420
iniziare a manipolare le informazioni che sono presenti all'interno del tuo database.

8
00:00:33,420 --> 00:00:36,578
Questa è ovviamente una situazione pericolosa.

9
00:00:36,578 --> 00:00:40,380
Il modo in cui il server dovrebbe essere implementato è che, è

10
00:00:40,380 --> 00:00:44,330
necessario avere una sorta di restrizione su

11
00:00:44,330 --> 00:00:48,660
quali tipi di utenti saranno autorizzati a eseguire quali tipi di operazioni.

12
00:00:48,660 --> 00:00:51,090
Quindi forse, consentiresti a

13
00:00:51,090 --> 00:00:54,650
un utente autorizzato solo di eseguire operazioni GET.

14
00:00:54,650 --> 00:01:00,040
Quindi, per esempio, se vuoi che un ospite sia in grado di vedere

15
00:01:00,040 --> 00:01:04,860
informazioni sui piatti nel tuo ristorante o

16
00:01:04,860 --> 00:01:07,250
sul menu del tuo ristorante e così via, questo è perfettamente accettabile.

17
00:01:07,250 --> 00:01:11,699
Tuttavia, è possibile consentire solo a un amministratore di entrare e

18
00:01:11,699 --> 00:01:17,780
modificare le informazioni sul piatto o di eliminare un piatto dal menu.

19
00:01:17,780 --> 00:01:23,448
E anche aggiornare un piatto esistente nel menu, o una promozione,

20
00:01:23,448 --> 00:01:29,062
o le informazioni sui leader nel vostro lato server.

21
00:01:29,062 --> 00:01:34,810
Ora, si potrebbe anche avere un altro gruppo di utenti che saranno registrati utenti

22
00:01:34,810 --> 00:01:39,980
che possono essere autorizzati a salvare alcuni dei loro piatti come loro piatti preferiti,

23
00:01:39,980 --> 00:01:44,290
e solo loro sarebbero in grado di manipolare l'elenco dei loro piatti preferiti.

24
00:01:44,290 --> 00:01:47,850
Quindi questo è un altro livello di autorizzazione o

25
00:01:47,850 --> 00:01:49,940
autenticazione che è necessario eseguire.

26
00:01:49,940 --> 00:01:53,400
Quindi, hai diversi gradi di utenti e

27
00:01:53,400 --> 00:01:57,820
anche, a seconda del tipo di operazioni che sarebbero autorizzati a eseguire.

28
00:01:57,820 --> 00:02:01,880
Quindi tutto ciò significa che hai bisogno di un qualche tipo di sicurezza per essere

29
00:02:01,880 --> 00:02:03,840
integrato nel tuo lato server.

30
00:02:03,840 --> 00:02:07,970
Vedremo come possiamo autenticare gli utenti e

31
00:02:07,970 --> 00:02:13,110
poi decidere che tipo di utente è questo client.

32
00:02:13,110 --> 00:02:15,410
E poi, a seconda del tipo di utente,

33
00:02:15,410 --> 00:02:19,360
è possibile consentire all'utente di eseguire determinati tipi di operazioni.

34
00:02:19,360 --> 00:02:24,630
Inizieremo con la comprensione di base di questo, ciò che chiamiamo come

35
00:02:24,630 --> 00:02:30,860
autenticazione di base in un lato server per

36
00:02:30,860 --> 00:02:36,940
un client, e poi, costruire su questo in tutto il resto di questo modulo.

37
00:02:36,940 --> 00:02:42,030
E poi alla fine di questo modulo, finiremo con un meccanismo

38
00:02:42,030 --> 00:02:46,170
, consentendo così agli utenti di registrarsi.

39
00:02:46,170 --> 00:02:50,220
Inoltre, gli utenti registrati possono eseguire determinate operazioni

40
00:02:50,220 --> 00:02:53,930
che un utente non registrato non può e così via.

41
00:02:53,930 --> 00:02:57,320
Quindi imporremo vari tipi di controlli di accesso per

42
00:02:57,320 --> 00:03:01,990
varie operazioni sul lato server in base al tipo di utente.

43
00:03:01,990 --> 00:03:04,930
Quindi questo ti imposta la prospettiva, o

44
00:03:04,930 --> 00:03:09,830
meglio l'idea di ciò che incontrerai in questo modulo.

45
00:03:09,830 --> 00:03:12,450
Iniziamo con l'autenticazione di base,

46
00:03:12,450 --> 00:03:18,450
il meccanismo di base che ci permetterà di autenticare gli utenti.

47
00:03:19,970 --> 00:03:25,173
L' autenticazione di base in HTTP è un meccanismo molto semplice,

48
00:03:25,173 --> 00:03:28,782
che chiederà all'utente un nome utente e una

49
00:03:28,782 --> 00:03:32,720
password da inviare con una richiesta.

50
00:03:32,720 --> 00:03:35,180
E c'è una struttura specifica

51
00:03:35,180 --> 00:03:39,920
su come queste informazioni verranno inviate dal client al lato server.

52
00:03:39,920 --> 00:03:45,060
Quindi, questa è una questione, l'autenticazione di accesso di base, che HTTP supporta,

53
00:03:45,060 --> 00:03:49,860
è una questione che consentirà a un server di sfidare un client e chiedere

54
00:03:49,860 --> 00:03:53,110
il nome utente e la password da inviare dal client.

55
00:03:53,110 --> 00:03:57,714
In questo modo il server può sfidare il client ad autenticarsi digitando queste

56
00:03:57,714 --> 00:03:59,140
informazioni.

57
00:03:59,140 --> 00:04:01,880
Il client deve inviare il nome utente e

58
00:04:01,880 --> 00:04:05,440
la password in risposta alla sfida dal lato server.

59
00:04:05,440 --> 00:04:09,870
Quindi, ogni messaggio di richiesta proveniente da un client

60
00:04:09,870 --> 00:04:13,870
dovrebbe includere la forma codificata del nome utente e

61
00:04:13,870 --> 00:04:19,700
della password nell'intestazione della richiesta che va dal client al lato server.

62
00:04:19,700 --> 00:04:22,229
Quindi, quando il server riceve la richiesta,

63
00:04:22,229 --> 00:04:27,009
il server estrarrà queste informazioni dall'intestazione della richiesta del client.

64
00:04:27,009 --> 00:04:31,831
E poi, usalo per autenticare il client prima di

65
00:04:31,831 --> 00:04:37,390
consentire l'accesso alle varie operazioni sul lato server.

66
00:04:37,390 --> 00:04:40,850
Quindi, come funziona questa autenticazione?

67
00:04:40,850 --> 00:04:44,450
Se un client invia una richiesta al server e

68
00:04:44,450 --> 00:04:50,150
questa richiesta client non include la formazione dell'autorizzazione, il server

69
00:04:50,150 --> 00:04:55,160
contesterà il client, sta chiedendo al client di inviare queste informazioni.

70
00:04:55,160 --> 00:04:58,100
Il server sfida il client includendo

71
00:04:58,100 --> 00:05:01,900
un'intestazione nel messaggio di risposta in arrivo.

72
00:05:01,900 --> 00:05:06,410
L' intestazione con il tipo come WWW-Authenticate e

73
00:05:06,410 --> 00:05:11,843
quindi la seconda parte in cui specifica il tipo è dove

74
00:05:11,843 --> 00:05:17,500
specificherà il tipo di autenticazione che il client deve inviare.

75
00:05:17,500 --> 00:05:21,990
E inizieremo con la comprensione dell'autenticazione di base qui.

76
00:05:21,990 --> 00:05:26,400
E si noti anche che il messaggio di risposta conterrà un codice di errore 401,

77
00:05:27,570 --> 00:05:31,270
che non è autorizzato, che significa non autorizzato.

78
00:05:31,270 --> 00:05:35,470
Quindi, quando la risposta ritorna dal lato server, il client,

79
00:05:35,470 --> 00:05:41,300
in risposta a questa risposta in arrivo, il client dovrà inviare la propria richiesta,

80
00:05:41,300 --> 00:05:49,550
includendo un campo di intestazione specifico nel messaggio di richiesta del tipo di autorizzazione.

81
00:05:49,550 --> 00:05:55,250
E questo campo di intestazione di autorizzazione conterrà alcune informazioni lì dentro.

82
00:05:55,250 --> 00:06:00,440
Per un'autenticazione di base, queste informazioni sarebbero sotto forma di,

83
00:06:00,440 --> 00:06:03,900
come la prima parola qui, sarà di base.

84
00:06:03,900 --> 00:06:11,410
E poi seguito da uno spazio qui, e seguito da una stringa codificata Base64 qui.

85
00:06:11,410 --> 00:06:15,358
Questa stringa codificata Base64 codifica il nome utente e

86
00:06:15,358 --> 00:06:21,350
la password in un formato particolare, e quindi include che nell'intestazione.

87
00:06:21,350 --> 00:06:25,479
Ora stai dicendo, se invii un messaggio di richiesta come questo,

88
00:06:25,479 --> 00:06:29,397
incluso questo, nell'intestazione, allora chiunque nel mezzo.

89
00:06:29,397 --> 00:06:33,538
Quindi, se sai qualcosa sulla sicurezza e su

90
00:06:33,538 --> 00:06:39,927
come possono essere lanciati gli attacchi dell'uomo nel mezzo, allora ovviamente,

91
00:06:39,927 --> 00:06:44,777
questo può essere recuperato da un intruso nel mezzo,

92
00:06:44,777 --> 00:06:49,590
e poi può essere usato per fingere il vero cliente.

93
00:06:49,590 --> 00:06:52,720
Ancora una volta, al momento non stiamo affrontando questa questione.

94
00:06:52,720 --> 00:06:57,470
Quando parlo di HTTPS nel prossimo modulo,

95
00:06:57,470 --> 00:07:00,880
tornerò per affrontare questo problema in modo un po 'più dettagliato.

96
00:07:00,880 --> 00:07:06,060
Ma per il momento, le informazioni nell'intestazione verranno inviate

97
00:07:07,880 --> 00:07:11,930
senza essere crittografate nell'intestazione in questo momento.

98
00:07:11,930 --> 00:07:15,460
Ora, un altro motivo per cui lo sto facendo è che, in modo che possiamo effettivamente guardare

99
00:07:15,460 --> 00:07:20,150
direttamente l'intestazione e quindi vedere queste informazioni nell'intestazione stessa.

100
00:07:20,150 --> 00:07:25,401
Quindi, quando il client invia questa richiesta, il server estrarrà

101
00:07:25,401 --> 00:07:30,930
le informazioni da questa intestazione di autorizzazione nell'intestazione della richiesta.

102
00:07:30,930 --> 00:07:35,078
E quindi utilizzare queste informazioni per verificare se si tratta di

103
00:07:35,078 --> 00:07:37,670
una richiesta client autorizzata o meno.

104
00:07:37,670 --> 00:07:40,412
Ora, naturalmente, la tua prossima domanda sarebbe,

105
00:07:40,412 --> 00:07:44,490
cosa contiene esattamente questa intestazione di autorizzazione?

106
00:07:44,490 --> 00:07:48,350
L' intestazione di autorizzazione stessa è costruita come segue.

107
00:07:48,350 --> 00:07:52,180
Se hai un nome utente e una password, queste sono le due

108
00:07:52,180 --> 00:07:55,730
informazioni che userai per autenticare un client.

109
00:07:55,730 --> 00:08:01,330
Quindi il nome utente e la password saranno concatenati in una singola stringa

110
00:08:01,330 --> 00:08:06,910
dicendo nome utente e due punti, e la password stessa.

111
00:08:06,910 --> 00:08:09,860
Quindi la stringa del nome utente, i due punti e

112
00:08:09,860 --> 00:08:16,210
la password saranno concatenati insieme in un'intera stringa qui.

113
00:08:16,210 --> 00:08:22,994
Questa stringa risultante che otteniamo qui è quella, codificata usando la codifica Base64.

114
00:08:22,994 --> 00:08:27,344
Se sai come la codifica viene eseguita le basi per la codifica,

115
00:08:27,344 --> 00:08:32,390
convertirlo in un'intestazione ASCII come mostrato in questo esempio qui,

116
00:08:32,390 --> 00:08:36,195
quindi questa non è altro che una stringa di intestazioni ASCII.

117
00:08:36,195 --> 00:08:39,545
Ora, se non sai molto sulla codifica rigida di base, non preoccuparti,

118
00:08:39,545 --> 00:08:44,325
non influisce sulla tua comprensione di ciò che sta succedendo qui comunque.

119
00:08:44,325 --> 00:08:47,090
Quindi questa stringa codificata Basic64, quindi

120
00:08:47,090 --> 00:08:51,950
questa particolare informazione è codificata in una stringa come questa, e

121
00:08:51,950 --> 00:08:57,090
quindi racchiusa nell'intestazione della richiesta che va dal client al server.

122
00:08:57,090 --> 00:09:02,143
L' intestazione della richiesta stessa è dell'autorizzazione del tipo,

123
00:09:02,143 --> 00:09:07,194
e quindi seguita dal valore effettivo qui, che dice,

124
00:09:07,194 --> 00:09:13,774
Basic, e uno spazio qui, e la stringa codificata Base64 qui.

125
00:09:13,774 --> 00:09:20,034
Quindi, quando questo viene ricevuto dal nostro server, il server estrarrà queste informazioni,

126
00:09:20,034 --> 00:09:25,059
e poi da qui, estrarrà il nome utente e la password, e

127
00:09:25,059 --> 00:09:31,620
quindi verificherà se corrisponde a un utente autorizzato o meno sul lato server.

128
00:09:31,620 --> 00:09:36,917
Per aiutarti a capire meglio come organizziamo effettivamente l'applicazione espressa

129
00:09:36,917 --> 00:09:42,211
e come viene eseguita l'autenticazione stessa, come abbiamo appreso in precedenza,

130
00:09:42,211 --> 00:09:47,520
le stesse applicazioni express sono organizzate in un set di middleware.

131
00:09:47,520 --> 00:09:51,690
E il modo in cui funziona l'applicazione espressa è che il middleware

132
00:09:51,690 --> 00:09:55,630
viene applicato alla richiesta e al messaggio di risposta

133
00:09:55,630 --> 00:10:00,940
nell'ordine in cui è dichiarato nella mia applicazione espressa.

134
00:10:00,940 --> 00:10:05,290
Quindi, se hai un express.use e

135
00:10:05,290 --> 00:10:09,740
poi hai il primo che dice un server statico, dopo di che,

136
00:10:09,740 --> 00:10:13,220
hai un altro middleware, poi hai un altro middleware.

137
00:10:13,220 --> 00:10:18,560
La sequenza in cui sono dichiarati nel file app.js dei server express,

138
00:10:18,560 --> 00:10:23,600
ad esempio, è la sequenza esatta in cui verrà applicato il middleware.

139
00:10:23,600 --> 00:10:29,124
Quindi una richiesta in arrivo dal lato server come si ricorda nell'

140
00:10:29,124 --> 00:10:34,690
applicazione espressa, la richiesta in arrivo viene trattata come un oggetto di richiesta.

141
00:10:34,690 --> 00:10:39,050
L' oggetto risposta è ciò che il server express costruisce, e

142
00:10:39,050 --> 00:10:43,310
quindi il successivo è consente di passare al middleware successivo

143
00:10:43,310 --> 00:10:45,910
che si sta per applicare, e così via.

144
00:10:45,910 --> 00:10:52,400
Quindi, una richiesta in arrivo come questa, quando arriva, viene applicato il primo middleware.

145
00:10:52,400 --> 00:10:56,164
E poi una volta che il middleware ha trasformato sia

146
00:10:56,164 --> 00:11:00,680
la richiesta che la risposta, passa al middleware successivo, che viene quindi applicato ad esso.

147
00:11:00,680 --> 00:11:03,940
Ad esempio, abbiamo visto che abbiamo applicato prima Morgan,

148
00:11:03,940 --> 00:11:06,930
poi abbiamo applicato il parser del corpo al middleware.

149
00:11:06,930 --> 00:11:12,930
Quindi devono aver già trasformato la richiesta e gli oggetti risposta.

150
00:11:12,930 --> 00:11:17,440
E poi, dopo, possiamo includere un middleware di autenticazione in atto lì.

151
00:11:17,440 --> 00:11:22,260
Il middleware di autenticazione autenticherà la richiesta.

152
00:11:22,260 --> 00:11:26,950
Ora, quindi se si utilizza l'autenticazione di base, la richiesta

153
00:11:26,950 --> 00:11:31,970
deve contenere nell'intestazione l'intestazione di autorizzazione in atto lì.

154
00:11:31,970 --> 00:11:36,260
Quindi l'intestazione di autorizzazione verrà estratta dal middleware di autenticazione

155
00:11:36,260 --> 00:11:40,180
e quindi controllata per vedere se l'utente è autorizzato.

156
00:11:40,180 --> 00:11:46,099
E se il middleware di autenticazione rileva che sei un utente autorizzato,

157
00:11:46,099 --> 00:11:50,515
allora ti sarà permesso di passare al set successivo di

158
00:11:50,515 --> 00:11:54,427
middleware che segue il passaggio di autenticazione.

159
00:11:54,427 --> 00:11:58,510
E i tuoi record saranno elaborati dal middleware successivo.

160
00:11:58,510 --> 00:11:59,519
Ma d'altra parte,

161
00:11:59,519 --> 00:12:04,422
se il middleware di autenticazione decide che non sei un utente autorizzato,

162
00:12:04,422 --> 00:12:09,197
allora il middleware di autenticazione ti porterà lungo un percorso diverso.

163
00:12:09,197 --> 00:12:13,975
Quindi generare un errore e quindi inviare

164
00:12:13,975 --> 00:12:19,368
una risposta di errore appropriata a quel lato client e

165
00:12:19,368 --> 00:12:24,010
verrà reindirizzato al gestore degli errori.

166
00:12:24,010 --> 00:12:28,450
Quindi questo reindirizzamento al gestore di errori verrà eseguito chiamando Next

167
00:12:28,450 --> 00:12:32,490
con l'errore come parametro a quello Next here.

168
00:12:32,490 --> 00:12:38,240
Quindi il prossimo è esattamente questo Avanti che vediamo nella risorsa richiesta Avanti qui.

169
00:12:38,240 --> 00:12:42,760
E così, questo ti porterà fino al gestore degli errori,

170
00:12:42,760 --> 00:12:48,170
che gestirà l'errore e quindi restituirà il messaggio di errore sul lato client,

171
00:12:48,170 --> 00:12:51,820
indicando il fallimento dell'autenticazione.

172
00:12:51,820 --> 00:12:56,720
Quindi questo è il modo in cui la tua tipica autorizzazione

173
00:12:56,720 --> 00:13:03,435
di base o autenticazione di base funziona nell'applicazione lato server.

174
00:13:03,435 --> 00:13:08,305
Avendo capito questo, passiamo all'esercizio in cui

175
00:13:08,305 --> 00:13:13,176
implementeremo l'autenticazione di base nella nostra applicazione e

176
00:13:13,176 --> 00:13:15,717
vedere come autentica gli utenti.

177
00:13:15,717 --> 00:13:17,952
[ MUSIC]