[MUSIC]
O servidor de API REST Express que implementamos no
módulo anterior permite que qualquer usuário execute qualquer uma das operações GET, POST ou DELETE.
Não há controle sobre quem pode executar esta operação.
Então, o que significa que,
se você executar um servidor como esse, então qualquer um pode entrar em seu servidor e
começar a manipular as informações que estão presentes em seu banco de dados.
Esta é, obviamente, uma situação perigosa.
A maneira como esse servidor deve ser implementado é que,
você precisa ter algum tipo de restrição sobre
quais tipos de usuários terão permissão para executar quais tipos de operações.
Então, talvez, você permitiria e
um usuário autorizado apenas para executar operações GET.
Assim, por exemplo, se você quiser que um convidado seja capaz de ver informações
sobre os pratos em seu restaurante ou o menu do seu restaurante e
assim por diante, isso é perfeitamente aceitável.
Mas, você pode permitir que apenas um administrador entre e
modifique as informações sobre o prato ou exclua um prato do menu.
E também atualizar um prato existente no menu, ou uma promoção,
ou as informações sobre os líderes no lado do servidor.
Agora, você também pode ter outro grupo de usuários que serão usuários registrados
que podem ser autorizados a salvar alguns de seus pratos como seus pratos favoritos,
e só eles seriam capazes de manipular a lista de seus pratos favoritos.
Portanto, esse é outro nível de autorização ou
autenticação que você precisa executar.
Então, você tem diferentes graus de usuários, e
também, dependendo do tipo de operações que eles teriam permissão para executar.
Então tudo isso significa que você precisa de algum tipo de segurança para ser
incorporado no lado do servidor.
Vamos analisar como podemos autenticar usuários e, em
seguida, decidir que tipo de usuário este cliente é.
E, em seguida, dependendo do tipo de usuário,
você pode permitir que o usuário execute certos tipos de operações.
Vamos começar com a compreensão básica disso, o que chamamos de
Autenticação Básica em um lado do servidor para
um cliente, e, em seguida, construir sobre isso durante todo o resto deste módulo.
E então, no final deste módulo, acabaremos com um mecanismo
, permitindo que os usuários se registrem.
E, os usuários registrados podem executar determinadas operações
que um usuário não registrado não pode, e assim por diante.
Então vamos impor vários tipos de controles de acesso para
várias operações no lado do servidor com base no tipo de usuário.
Então isso define a perspectiva, ou
melhor, a idéia do que você vai encontrar neste módulo.
Vamos começar com a autenticação básica,
o mecanismo muito básico que nos permitirá autenticar usuários. A
autenticação básica em HTTP é um mecanismo muito simples,
que pedirá ao usuário um nome de usuário e
senha a serem enviados com uma solicitação.
E há uma estrutura específica
sobre como essas informações serão enviadas do cliente para o lado do servidor.
Então, esta é uma questão, a autenticação básica de acesso, que HTTP suporta,
é uma questão que permitirá que um servidor desafie um cliente, e pedir que
o nome de usuário e senha sejam enviados pelo cliente.
Assim, o servidor pode desafiar o cliente a se autenticar digitando essas
informações.
O cliente precisa enviar o nome de usuário e a
senha em resposta ao desafio do lado do servidor.
Assim, cada mensagem de solicitação originada de um cliente
deve incluir a forma codificada do nome de usuário e
senha no cabeçalho de solicitação que vai do cliente para o lado do servidor.
Assim, quando o servidor recebe a solicitação,
o servidor irá extrair essas informações do cabeçalho de solicitação do cliente.
E, em seguida, use isso para autenticar o cliente antes de
permitir o acesso às várias operações no lado do servidor.
Então, como funciona essa autenticação?
Se um cliente envia uma solicitação para o servidor e
essa solicitação de cliente não inclui a formação de autorização, então o servidor
desafiará o cliente, ele está solicitando que o cliente envie essas informações.
O servidor desafia o cliente, incluindo
um cabeçalho na mensagem de resposta que entra.
O cabeçalho com o tipo como WWW-Authenticate e,
em seguida, a segunda parte onde ele especifica o tipo é onde ele irá
especificar que tipo de autenticação o cliente precisa enviar.
E vamos começar com a compreensão da autenticação básica aqui.
E observe também que a mensagem de resposta conterá um código de erro 401,
que é não autorizado, o que significa não autorizado.
Então, quando a resposta voltar do lado do servidor, em seguida, o cliente,
em resposta a esta resposta chegando, o cliente terá que enviar sua solicitação,
incluindo um campo de cabeçalho específico na mensagem de solicitação do tipo autorização.
E este campo de cabeçalho de autorização conterá algumas informações lá.
Para uma autenticação básica, esta informação seria na forma de,
como a primeira palavra aqui, será Básica.
E então seguido por um espaço aqui, e seguido por uma string codificada Base64 aqui.
Essa string codificada Base64 codifica o nome de usuário e
a senha em um formato específico e, em seguida, inclui isso no cabeçalho.
Agora você está dizendo, se você enviar uma mensagem de solicitação como esta,
incluindo esta, no cabeçalho, então qualquer um no meio.
Então, se você sabe alguma coisa sobre segurança e
como os ataques do homem no meio podem ser lançados, então, obviamente,
isso pode ser recuperado por um intruso no meio,
e então pode ser usado para fingir o cliente real.
Mais uma vez, não estamos a entrar nesta questão neste momento.
Quando falo sobre HTTPS no próximo módulo,
voltarei a abordar esse problema com um pouco mais de detalhes.
Mas, por enquanto, as informações no cabeçalho serão enviadas
sem serem criptografadas no cabeçalho neste momento.
Agora, uma outra razão pela qual eu estou fazendo isso é que, para que possamos realmente olhar para
o cabeçalho diretamente e, em seguida, ver essa informação no próprio cabeçalho.
Assim, quando o cliente envia esta solicitação, em seguida, o servidor irá extrair
as informações deste cabeçalho de autorização no cabeçalho de solicitação.
E, em seguida, use essas informações para verificar se este é
um pedido de cliente autorizado ou não.
Agora, é claro, sua próxima pergunta seria,
o que exatamente esse cabeçalho de autorização contém?
O cabeçalho de autorização em si é construído da seguinte forma.
Se você tiver um nome de usuário e uma senha, estas são
as duas informações que você usará para autenticar um cliente.
Assim, o nome de usuário e senha serão concatenados em uma única string
dizendo nome de usuário e dois pontos, e a senha em si.
Assim, a string de nome de usuário, dois pontos e
senha serão concatenados juntos em uma string inteira aqui.
Esta string resultante que temos aqui é que, codificado usando codificação Base64.
Se você sabe sobre como a codificação é feita noções básicas para codificação,
converta isso em um cabeçalho ASCII como mostrado neste exemplo aqui,
então isso não é nada além de uma string de cabeçalhos ASCII.
Agora, se você não sabe muito sobre codificação rígida básica, não se preocupe com isso,
isso não afeta sua compreensão do que está acontecendo aqui de qualquer maneira.
Então esta Basic64 strings codificadas, então
essa informação específica é codificada em uma string como esta, e
então incluída no cabeçalho de solicitação indo do cliente para o servidor.
O cabeçalho de solicitação em si é da autorização de tipo
e, em seguida, seguido pelo valor real aqui, que diz,
Básico, e um espaço aqui, e a string codificada Base64 aqui.
Então, quando isso é recebido pelo nosso servidor, o servidor irá extrair esta informação,
e então a partir daqui, ele irá extrair o nome de usuário e senha, e
então verificar se isso corresponde a um usuário autorizado ou não no lado do servidor.
Para ajudá-lo a entender melhor como realmente organizamos o aplicativo expresso
e como a autenticação em si é realizada, como aprendemos anteriormente, os
próprios aplicativos expressos são organizados em um conjunto de middleware.
E a maneira como o aplicativo expresso funciona é que o middleware
são aplicados ao pedido e à mensagem de resposta
na ordem em que é declarado na minha aplicação expressa.
Então, se você tem um express.use e
então você tem o primeiro dizendo um servidor estático, depois disso,
você tem outro middleware, depois disso, você tem outro middleware.
A seqüência em que eles são declarados no arquivo app.js de servidores expressos,
por exemplo, é a seqüência exata na qual o middleware será aplicado.
Assim, uma solicitação de entrada do lado do servidor como você se lembra em sua
aplicação expressa, a solicitação de entrada é tratada como um objeto de solicitação.
O objeto de resposta é o que o servidor express constrói e,
em seguida, o próximo é permite que você vá para o próximo middleware
que você vai aplicar, e assim por diante.
Então, uma solicitação de entrada como esta, quando ele entra, o primeiro middleware é aplicado.
E então, uma vez que o middleware transformou tanto
a solicitação quanto a resposta, ele passa para o próximo middleware, que é então aplicado a ele.
Então, por exemplo, vimos que aplicamos Morgan primeiro,
depois aplicamos o analisador de corpo ao middleware.
Então eles já devem ter transformado o pedido e os objetos de resposta.
E depois disso, podemos incluir um middleware de autenticação no local.
O middleware de autenticação vai autenticar a solicitação.
Agora, então, se você estiver usando autenticação básica, faça a sua solicitação
deve conter no cabeçalho o cabeçalho de autorização no lugar lá.
Assim, o cabeçalho de autorização será extraído pelo middleware de autenticação
e, em seguida, verificado para ver se o usuário está autorizado.
E se o middleware de autenticação detectar que você é um usuário autorizado,
então você terá permissão para avançar para o próximo conjunto de
middleware que segue a etapa de autenticação.
E seus registros serão processados pelo middleware subsequente.
Mas, por outro lado,
se o middleware de autenticação decidir que você não é um usuário autorizado,
então o middleware de autenticação o levará ao longo de um caminho diferente fora.
E, em seguida, gerar um erro e, em seguida, enviar de volta
uma resposta de erro apropriada para esse lado do cliente e
será redirecionado para o manipulador de erros.
Então este redirecionamento para o manipulador de erros será feito chamando Next
com o erro como o parâmetro para que Next aqui.
Então o Próximo é exatamente este Próximo que vemos no recurso de solicitação Próximo aqui.
E assim, isso irá levá-lo até o manipulador de erros,
que irá lidar com o erro e, em seguida, enviar de volta a mensagem de erro para o lado do cliente,
indicando a falha da autenticação.
Portanto, é assim que sua autorização básica típica ou
autenticação básica funciona em seu aplicativo do lado do servidor.
Tendo entendido isso, vamos passar para o exercício onde
vamos implementar a autenticação básica em nosso aplicativo e
ver como ele autentica usuários.
[ MUSIC]