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

2
00:00:04,470 --> 00:00:10,326
O servidor de API REST Express que implementamos no

3
00:00:10,326 --> 00:00:17,750
módulo anterior permite que qualquer usuário execute qualquer uma das operações GET, POST ou DELETE.

4
00:00:17,750 --> 00:00:21,360
Não há controle sobre quem pode executar esta operação.

5
00:00:21,360 --> 00:00:22,350
Então, o que significa que,

6
00:00:22,350 --> 00:00:27,180
se você executar um servidor como esse, então qualquer um pode entrar em seu servidor e

7
00:00:27,180 --> 00:00:33,420
começar a manipular as informações que estão presentes em seu banco de dados.

8
00:00:33,420 --> 00:00:36,578
Esta é, obviamente, uma situação perigosa.

9
00:00:36,578 --> 00:00:40,380
A maneira como esse servidor deve ser implementado é que,

10
00:00:40,380 --> 00:00:44,330
você precisa ter algum tipo de restrição sobre

11
00:00:44,330 --> 00:00:48,660
quais tipos de usuários terão permissão para executar quais tipos de operações.

12
00:00:48,660 --> 00:00:51,090
Então, talvez, você permitiria e

13
00:00:51,090 --> 00:00:54,650
um usuário autorizado apenas para executar operações GET.

14
00:00:54,650 --> 00:01:00,040
Assim, por exemplo, se você quiser que um convidado seja capaz de ver informações

15
00:01:00,040 --> 00:01:04,860
sobre os pratos em seu restaurante ou o menu do seu restaurante e

16
00:01:04,860 --> 00:01:07,250
assim por diante, isso é perfeitamente aceitável.

17
00:01:07,250 --> 00:01:11,699
Mas, você pode permitir que apenas um administrador entre e

18
00:01:11,699 --> 00:01:17,780
modifique as informações sobre o prato ou exclua um prato do menu.

19
00:01:17,780 --> 00:01:23,448
E também atualizar um prato existente no menu, ou uma promoção,

20
00:01:23,448 --> 00:01:29,062
ou as informações sobre os líderes no lado do servidor.

21
00:01:29,062 --> 00:01:34,810
Agora, você também pode ter outro grupo de usuários que serão usuários registrados

22
00:01:34,810 --> 00:01:39,980
que podem ser autorizados a salvar alguns de seus pratos como seus pratos favoritos,

23
00:01:39,980 --> 00:01:44,290
e só eles seriam capazes de manipular a lista de seus pratos favoritos.

24
00:01:44,290 --> 00:01:47,850
Portanto, esse é outro nível de autorização ou

25
00:01:47,850 --> 00:01:49,940
autenticação que você precisa executar.

26
00:01:49,940 --> 00:01:53,400
Então, você tem diferentes graus de usuários, e

27
00:01:53,400 --> 00:01:57,820
também, dependendo do tipo de operações que eles teriam permissão para executar.

28
00:01:57,820 --> 00:02:01,880
Então tudo isso significa que você precisa de algum tipo de segurança para ser

29
00:02:01,880 --> 00:02:03,840
incorporado no lado do servidor.

30
00:02:03,840 --> 00:02:07,970
Vamos analisar como podemos autenticar usuários e, em

31
00:02:07,970 --> 00:02:13,110
seguida, decidir que tipo de usuário este cliente é.

32
00:02:13,110 --> 00:02:15,410
E, em seguida, dependendo do tipo de usuário,

33
00:02:15,410 --> 00:02:19,360
você pode permitir que o usuário execute certos tipos de operações.

34
00:02:19,360 --> 00:02:24,630
Vamos começar com a compreensão básica disso, o que chamamos de

35
00:02:24,630 --> 00:02:30,860
Autenticação Básica em um lado do servidor para

36
00:02:30,860 --> 00:02:36,940
um cliente, e, em seguida, construir sobre isso durante todo o resto deste módulo.

37
00:02:36,940 --> 00:02:42,030
E então, no final deste módulo, acabaremos com um mecanismo

38
00:02:42,030 --> 00:02:46,170
, permitindo que os usuários se registrem.

39
00:02:46,170 --> 00:02:50,220
E, os usuários registrados podem executar determinadas operações

40
00:02:50,220 --> 00:02:53,930
que um usuário não registrado não pode, e assim por diante.

41
00:02:53,930 --> 00:02:57,320
Então vamos impor vários tipos de controles de acesso para

42
00:02:57,320 --> 00:03:01,990
várias operações no lado do servidor com base no tipo de usuário.

43
00:03:01,990 --> 00:03:04,930
Então isso define a perspectiva, ou

44
00:03:04,930 --> 00:03:09,830
melhor, a idéia do que você vai encontrar neste módulo.

45
00:03:09,830 --> 00:03:12,450
Vamos começar com a autenticação básica,

46
00:03:12,450 --> 00:03:18,450
o mecanismo muito básico que nos permitirá autenticar usuários. A

47
00:03:19,970 --> 00:03:25,173
autenticação básica em HTTP é um mecanismo muito simples,

48
00:03:25,173 --> 00:03:28,782
que pedirá ao usuário um nome de usuário e

49
00:03:28,782 --> 00:03:32,720
senha a serem enviados com uma solicitação.

50
00:03:32,720 --> 00:03:35,180
E há uma estrutura específica

51
00:03:35,180 --> 00:03:39,920
sobre como essas informações serão enviadas do cliente para o lado do servidor.

52
00:03:39,920 --> 00:03:45,060
Então, esta é uma questão, a autenticação básica de acesso, que HTTP suporta,

53
00:03:45,060 --> 00:03:49,860
é uma questão que permitirá que um servidor desafie um cliente, e pedir que

54
00:03:49,860 --> 00:03:53,110
o nome de usuário e senha sejam enviados pelo cliente.

55
00:03:53,110 --> 00:03:57,714
Assim, o servidor pode desafiar o cliente a se autenticar digitando essas

56
00:03:57,714 --> 00:03:59,140
informações.

57
00:03:59,140 --> 00:04:01,880
O cliente precisa enviar o nome de usuário e a

58
00:04:01,880 --> 00:04:05,440
senha em resposta ao desafio do lado do servidor.

59
00:04:05,440 --> 00:04:09,870
Assim, cada mensagem de solicitação originada de um cliente

60
00:04:09,870 --> 00:04:13,870
deve incluir a forma codificada do nome de usuário e

61
00:04:13,870 --> 00:04:19,700
senha no cabeçalho de solicitação que vai do cliente para o lado do servidor.

62
00:04:19,700 --> 00:04:22,229
Assim, quando o servidor recebe a solicitação,

63
00:04:22,229 --> 00:04:27,009
o servidor irá extrair essas informações do cabeçalho de solicitação do cliente.

64
00:04:27,009 --> 00:04:31,831
E, em seguida, use isso para autenticar o cliente antes de

65
00:04:31,831 --> 00:04:37,390
permitir o acesso às várias operações no lado do servidor.

66
00:04:37,390 --> 00:04:40,850
Então, como funciona essa autenticação?

67
00:04:40,850 --> 00:04:44,450
Se um cliente envia uma solicitação para o servidor e

68
00:04:44,450 --> 00:04:50,150
essa solicitação de cliente não inclui a formação de autorização, então o servidor

69
00:04:50,150 --> 00:04:55,160
desafiará o cliente, ele está solicitando que o cliente envie essas informações.

70
00:04:55,160 --> 00:04:58,100
O servidor desafia o cliente, incluindo

71
00:04:58,100 --> 00:05:01,900
um cabeçalho na mensagem de resposta que entra.

72
00:05:01,900 --> 00:05:06,410
O cabeçalho com o tipo como WWW-Authenticate e,

73
00:05:06,410 --> 00:05:11,843
em seguida, a segunda parte onde ele especifica o tipo é onde ele irá

74
00:05:11,843 --> 00:05:17,500
especificar que tipo de autenticação o cliente precisa enviar.

75
00:05:17,500 --> 00:05:21,990
E vamos começar com a compreensão da autenticação básica aqui.

76
00:05:21,990 --> 00:05:26,400
E observe também que a mensagem de resposta conterá um código de erro 401,

77
00:05:27,570 --> 00:05:31,270
que é não autorizado, o que significa não autorizado.

78
00:05:31,270 --> 00:05:35,470
Então, quando a resposta voltar do lado do servidor, em seguida, o cliente,

79
00:05:35,470 --> 00:05:41,300
em resposta a esta resposta chegando, o cliente terá que enviar sua solicitação,

80
00:05:41,300 --> 00:05:49,550
incluindo um campo de cabeçalho específico na mensagem de solicitação do tipo autorização.

81
00:05:49,550 --> 00:05:55,250
E este campo de cabeçalho de autorização conterá algumas informações lá.

82
00:05:55,250 --> 00:06:00,440
Para uma autenticação básica, esta informação seria na forma de,

83
00:06:00,440 --> 00:06:03,900
como a primeira palavra aqui, será Básica.

84
00:06:03,900 --> 00:06:11,410
E então seguido por um espaço aqui, e seguido por uma string codificada Base64 aqui.

85
00:06:11,410 --> 00:06:15,358
Essa string codificada Base64 codifica o nome de usuário e

86
00:06:15,358 --> 00:06:21,350
a senha em um formato específico e, em seguida, inclui isso no cabeçalho.

87
00:06:21,350 --> 00:06:25,479
Agora você está dizendo, se você enviar uma mensagem de solicitação como esta,

88
00:06:25,479 --> 00:06:29,397
incluindo esta, no cabeçalho, então qualquer um no meio.

89
00:06:29,397 --> 00:06:33,538
Então, se você sabe alguma coisa sobre segurança e

90
00:06:33,538 --> 00:06:39,927
como os ataques do homem no meio podem ser lançados, então, obviamente,

91
00:06:39,927 --> 00:06:44,777
isso pode ser recuperado por um intruso no meio,

92
00:06:44,777 --> 00:06:49,590
e então pode ser usado para fingir o cliente real.

93
00:06:49,590 --> 00:06:52,720
Mais uma vez, não estamos a entrar nesta questão neste momento.

94
00:06:52,720 --> 00:06:57,470
Quando falo sobre HTTPS no próximo módulo,

95
00:06:57,470 --> 00:07:00,880
voltarei a abordar esse problema com um pouco mais de detalhes.

96
00:07:00,880 --> 00:07:06,060
Mas, por enquanto, as informações no cabeçalho serão enviadas

97
00:07:07,880 --> 00:07:11,930
sem serem criptografadas no cabeçalho neste momento.

98
00:07:11,930 --> 00:07:15,460
Agora, uma outra razão pela qual eu estou fazendo isso é que, para que possamos realmente olhar para

99
00:07:15,460 --> 00:07:20,150
o cabeçalho diretamente e, em seguida, ver essa informação no próprio cabeçalho.

100
00:07:20,150 --> 00:07:25,401
Assim, quando o cliente envia esta solicitação, em seguida, o servidor irá extrair

101
00:07:25,401 --> 00:07:30,930
as informações deste cabeçalho de autorização no cabeçalho de solicitação.

102
00:07:30,930 --> 00:07:35,078
E, em seguida, use essas informações para verificar se este é

103
00:07:35,078 --> 00:07:37,670
um pedido de cliente autorizado ou não.

104
00:07:37,670 --> 00:07:40,412
Agora, é claro, sua próxima pergunta seria,

105
00:07:40,412 --> 00:07:44,490
o que exatamente esse cabeçalho de autorização contém?

106
00:07:44,490 --> 00:07:48,350
O cabeçalho de autorização em si é construído da seguinte forma.

107
00:07:48,350 --> 00:07:52,180
Se você tiver um nome de usuário e uma senha, estas são

108
00:07:52,180 --> 00:07:55,730
as duas informações que você usará para autenticar um cliente.

109
00:07:55,730 --> 00:08:01,330
Assim, o nome de usuário e senha serão concatenados em uma única string

110
00:08:01,330 --> 00:08:06,910
dizendo nome de usuário e dois pontos, e a senha em si.

111
00:08:06,910 --> 00:08:09,860
Assim, a string de nome de usuário, dois pontos e

112
00:08:09,860 --> 00:08:16,210
senha serão concatenados juntos em uma string inteira aqui.

113
00:08:16,210 --> 00:08:22,994
Esta string resultante que temos aqui é que, codificado usando codificação Base64.

114
00:08:22,994 --> 00:08:27,344
Se você sabe sobre como a codificação é feita noções básicas para codificação,

115
00:08:27,344 --> 00:08:32,390
converta isso em um cabeçalho ASCII como mostrado neste exemplo aqui,

116
00:08:32,390 --> 00:08:36,195
então isso não é nada além de uma string de cabeçalhos ASCII.

117
00:08:36,195 --> 00:08:39,545
Agora, se você não sabe muito sobre codificação rígida básica, não se preocupe com isso,

118
00:08:39,545 --> 00:08:44,325
isso não afeta sua compreensão do que está acontecendo aqui de qualquer maneira.

119
00:08:44,325 --> 00:08:47,090
Então esta Basic64 strings codificadas, então

120
00:08:47,090 --> 00:08:51,950
essa informação específica é codificada em uma string como esta, e

121
00:08:51,950 --> 00:08:57,090
então incluída no cabeçalho de solicitação indo do cliente para o servidor.

122
00:08:57,090 --> 00:09:02,143
O cabeçalho de solicitação em si é da autorização de tipo

123
00:09:02,143 --> 00:09:07,194
e, em seguida, seguido pelo valor real aqui, que diz,

124
00:09:07,194 --> 00:09:13,774
Básico, e um espaço aqui, e a string codificada Base64 aqui.

125
00:09:13,774 --> 00:09:20,034
Então, quando isso é recebido pelo nosso servidor, o servidor irá extrair esta informação,

126
00:09:20,034 --> 00:09:25,059
e então a partir daqui, ele irá extrair o nome de usuário e senha, e

127
00:09:25,059 --> 00:09:31,620
então verificar se isso corresponde a um usuário autorizado ou não no lado do servidor.

128
00:09:31,620 --> 00:09:36,917
Para ajudá-lo a entender melhor como realmente organizamos o aplicativo expresso

129
00:09:36,917 --> 00:09:42,211
e como a autenticação em si é realizada, como aprendemos anteriormente, os

130
00:09:42,211 --> 00:09:47,520
próprios aplicativos expressos são organizados em um conjunto de middleware.

131
00:09:47,520 --> 00:09:51,690
E a maneira como o aplicativo expresso funciona é que o middleware

132
00:09:51,690 --> 00:09:55,630
são aplicados ao pedido e à mensagem de resposta

133
00:09:55,630 --> 00:10:00,940
na ordem em que é declarado na minha aplicação expressa.

134
00:10:00,940 --> 00:10:05,290
Então, se você tem um express.use e

135
00:10:05,290 --> 00:10:09,740
então você tem o primeiro dizendo um servidor estático, depois disso,

136
00:10:09,740 --> 00:10:13,220
você tem outro middleware, depois disso, você tem outro middleware.

137
00:10:13,220 --> 00:10:18,560
A seqüência em que eles são declarados no arquivo app.js de servidores expressos,

138
00:10:18,560 --> 00:10:23,600
por exemplo, é a seqüência exata na qual o middleware será aplicado.

139
00:10:23,600 --> 00:10:29,124
Assim, uma solicitação de entrada do lado do servidor como você se lembra em sua

140
00:10:29,124 --> 00:10:34,690
aplicação expressa, a solicitação de entrada é tratada como um objeto de solicitação.

141
00:10:34,690 --> 00:10:39,050
O objeto de resposta é o que o servidor express constrói e,

142
00:10:39,050 --> 00:10:43,310
em seguida, o próximo é permite que você vá para o próximo middleware

143
00:10:43,310 --> 00:10:45,910
que você vai aplicar, e assim por diante.

144
00:10:45,910 --> 00:10:52,400
Então, uma solicitação de entrada como esta, quando ele entra, o primeiro middleware é aplicado.

145
00:10:52,400 --> 00:10:56,164
E então, uma vez que o middleware transformou tanto

146
00:10:56,164 --> 00:11:00,680
a solicitação quanto a resposta, ele passa para o próximo middleware, que é então aplicado a ele.

147
00:11:00,680 --> 00:11:03,940
Então, por exemplo, vimos que aplicamos Morgan primeiro,

148
00:11:03,940 --> 00:11:06,930
depois aplicamos o analisador de corpo ao middleware.

149
00:11:06,930 --> 00:11:12,930
Então eles já devem ter transformado o pedido e os objetos de resposta.

150
00:11:12,930 --> 00:11:17,440
E depois disso, podemos incluir um middleware de autenticação no local.

151
00:11:17,440 --> 00:11:22,260
O middleware de autenticação vai autenticar a solicitação.

152
00:11:22,260 --> 00:11:26,950
Agora, então, se você estiver usando autenticação básica, faça a sua solicitação

153
00:11:26,950 --> 00:11:31,970
deve conter no cabeçalho o cabeçalho de autorização no lugar lá.

154
00:11:31,970 --> 00:11:36,260
Assim, o cabeçalho de autorização será extraído pelo middleware de autenticação

155
00:11:36,260 --> 00:11:40,180
e, em seguida, verificado para ver se o usuário está autorizado.

156
00:11:40,180 --> 00:11:46,099
E se o middleware de autenticação detectar que você é um usuário autorizado,

157
00:11:46,099 --> 00:11:50,515
então você terá permissão para avançar para o próximo conjunto de

158
00:11:50,515 --> 00:11:54,427
middleware que segue a etapa de autenticação.

159
00:11:54,427 --> 00:11:58,510
E seus registros serão processados pelo middleware subsequente.

160
00:11:58,510 --> 00:11:59,519
Mas, por outro lado,

161
00:11:59,519 --> 00:12:04,422
se o middleware de autenticação decidir que você não é um usuário autorizado,

162
00:12:04,422 --> 00:12:09,197
então o middleware de autenticação o levará ao longo de um caminho diferente fora.

163
00:12:09,197 --> 00:12:13,975
E, em seguida, gerar um erro e, em seguida, enviar de volta

164
00:12:13,975 --> 00:12:19,368
uma resposta de erro apropriada para esse lado do cliente e

165
00:12:19,368 --> 00:12:24,010
será redirecionado para o manipulador de erros.

166
00:12:24,010 --> 00:12:28,450
Então este redirecionamento para o manipulador de erros será feito chamando Next

167
00:12:28,450 --> 00:12:32,490
com o erro como o parâmetro para que Next aqui.

168
00:12:32,490 --> 00:12:38,240
Então o Próximo é exatamente este Próximo que vemos no recurso de solicitação Próximo aqui.

169
00:12:38,240 --> 00:12:42,760
E assim, isso irá levá-lo até o manipulador de erros,

170
00:12:42,760 --> 00:12:48,170
que irá lidar com o erro e, em seguida, enviar de volta a mensagem de erro para o lado do cliente,

171
00:12:48,170 --> 00:12:51,820
indicando a falha da autenticação.

172
00:12:51,820 --> 00:12:56,720
Portanto, é assim que sua autorização básica típica ou

173
00:12:56,720 --> 00:13:03,435
autenticação básica funciona em seu aplicativo do lado do servidor.

174
00:13:03,435 --> 00:13:08,305
Tendo entendido isso, vamos passar para o exercício onde

175
00:13:08,305 --> 00:13:13,176
vamos implementar a autenticação básica em nosso aplicativo e

176
00:13:13,176 --> 00:13:15,717
ver como ele autentica usuários.

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