[MÚSICA]
Na lição anterior, aprendemos sobre autenticação básica.
Vimos que na autenticação básica o cliente terá que manter explicitamente
adicionando no campo de autorização que contém o nome de usuário e
senha para cada solicitação que o cliente envia para o lado do servidor.
Agora isso é perfeitamente bom para autenticação simples.
Os cookies são mais um mecanismo que é fornecido que permite que o seu servidor
seja capaz de esperar que o cliente armazene algumas informações no lado do cliente e
inclua essas informações explicitamente em cada solicitação de saída.
Assim, em vez de incluir seu nome de usuário codificado com base 64 e
senha, como fizemos na autenticação básica, usando cookies,
seu servidor pode configurar uma informação explícita no lado do cliente
, que será incluída em cada solicitação de saída do lado do cliente.
Agora, expandindo isso ainda mais, se o servidor quiser rastrear informações sobre seu
cliente, então o servidor pode configurar explicitamente um mecanismo de rastreamento de sessão.
Agora, os cookies são pequenos e não podem armazenar muita informação lá,
e isso, claro, não pode ser incluído na solicitação de saída.
Os cookies podem incluir algumas informações básicas
no cabeçalho da solicitação de saída do cliente.
Agora, se queremos muito mais informações a serem rastreadas sobre um cliente
no lado do servidor, então sessões expressas nos permitem fazer isso.
Vamos estudar mais sobre cookies e
sessões Express com um pouco mais de detalhes nesta lição e
também explorá-los ainda mais nos exercícios que se seguem a esta palestra.
Então, o que são cookies HTTP?
Os cookies HTTP, como mencionei, são pequenos pedaços de dados que são enviados
de um servidor web e são armazenados no lado do cliente.
Agora, quase todos os navegadores têm a capacidade de suportar
o armazenamento de cookies no lado do cliente e incluí-los automaticamente
na solicitação quando a solicitação é enviada para um servidor específico.
Assim, cada solicitação subsequente do
lado do cliente incluirá um novo cabeçalho lá
com o cookie no cabeçalho da solicitação.
Agora, obviamente, se você viu que a imprensa popular tem uma má reputação
lá, isso, é claro, não é completamente imerecido.
Mas é explodido muito fora de proporção do que o que é realmente a verdade.
Então pegue qualquer coisa que você lê na imprensa popular sobre biscoitos e
sua má reputação com um grão de sal.
Os cookies são muito úteis para fazer muitas coisas interessantes.
E podemos garantir que os cookies possam ter integridade suficiente
incorporada neles para que eles não possam ser manipulados por ninguém no meio.
Agora, como essa inclusão de configuração de cookie na solicitação de saída funciona?
Quando um cliente envia uma solicitação para o site do servidor,
se o cliente é autenticado no site do servidor.
Por exemplo, usando a autenticação básica,
então o servidor pode, em troca, configurar um cookie.
Agora, para configurar um cookie no site do cliente, o servidor incluirá
na mensagem de resposta um cabeçalho com o cabeçalho do cookie enviado e
o cookie real no cabeçalho.
Agora, quando o cliente recebe a mensagem de resposta do servidor que contém
o cabeçalho Set-Cookie, ele irá configurar o cookie no lado do cliente.
De modo que cada solicitação subsequente indo do lado do cliente
incluirá explicitamente um campo de cabeçalho chamado como cookie e
cabeçalho real que contém como
o valor, as informações de cookie que foram enviadas pelo servidor na mensagem de resposta.
Assim, cada mensagem de solicitação subseqüente levará este cookie no cabeçalho.
Assim, quando o servidor recebe esta mensagem de solicitação, ele é capaz de examinar
o cookie e supor de quem esta solicitação está vindo.
Assim, ele é capaz de reconhecer o cliente olhando para as informações de cookie.
Portanto, é aqui que os cookies são muito úteis
para poder enviar informações de autorização.
Assim, em servir incluindo nome de usuário e senha como parte do
cabeçalho de autenticação básica em cada solicitação em andamento.
Na primeira vez que você se autentica, você envia seu nome de usuário e senha e
o servidor configura o cookie do seu lado.
Posteriormente, você só precisa incluir o cookie na solicitação de saída.
Agora, os cookies também podem ter uma data de validade associada a eles.
Assim, nesse ponto, o cookie será considerado como expirado e
não será mais válido.
Portanto, essa é uma forma de controlar a duração para a
qual uma autorização é válida.
Chegando ao Express em si, como é que o Express suporta cookies?
Agora, como entendemos, o Express usa um monte de middleware.
Este é o lugar onde um dos middlewares que entra chamado o analisador de cookies
chega ao nosso aplicativo às oito.
O analisador de cookies permite que o servidor configure um cookie no cabeçalho de resposta.
Então isso é feito usando res.cookie e o nome e
certos valores e as opções como veremos no exercício mais tarde.
Assim, os cookies, quando são enviados do lado do cliente, incluídos nessa
mensagem de solicitação são analisados no lado do servidor Express, usando o analisador de cookies.
O middleware do analisador de cookies,
que, quando instalado, permitirá que você analise os cookies recebidos.
E, em seguida, estes cookies de entrada serão adicionados
à solicitação como um cabeçalho e podem ser examinados no lado do servidor.
Agora, a fim de proteger a autenticidade do cookie,
os próprios cookies podem ser assinados pelo servidor.
Agora, quando o servidor assina um cookie, o servidor usa uma chave secreta,
que só é conhecida pelo lado do servidor.
Agora, se você sabe alguma coisa sobre segurança do computador, criptografia e
criptografia, então você entende o que assinar e chaves secretas e
chaves públicas e todas essas coisas significam.
Se você não fizer isso, basta dizer que uma chave secreta é
uma string específica que só o servidor conhece e ninguém mais sabe.
Assim, quando um servidor criptografa um cookie, ele usará uma chave secreta como assinatura e
criará o que é chamado de código de autenticação de mensagem de hash de chave.
E inclui isso no cookie que é enviado do servidor para o lado do cliente.
Este HMAC que é criado no lado do servidor só pode ser feito
por esse servidor específico sabendo que a chave secreta.
Agora, uma vez que o servidor é um recurso protegido, então
apenas o servidor saberá a chave secreta e por isso é muito fácil verificar
quando um cookie assinado é enviado do lado do cliente para o lado do servidor.
Assim, quando o cookie assinado é enviado do lado do cliente para o lado do servidor,
o cookie será configurado no lado do cliente e, em
seguida, todas as solicitações subsequentes incluirão este cookie assinado no lado do cliente.
Agora, o middleware do analisador de cookies que configuramos com o nosso servidor Express
já suporta cookies assinados.
Agora, para isso, no analisador de cookies, você também fornecerá a chave secreta como
o parâmetro para o analisador de cookies quando você configurar o middleware do analisador de cookies.
Assim, todos os cookies serão assinados de forma adequada e depois enviados.
E quando o cookie é analisado no lado do servidor na
mensagem de solicitação de entrada, isso será adicionado à mensagem de solicitação como Req.signedCookies.
E então você pode ter um campo específico que você pode verificar no cookie assinado.
Cookies são uma forma muito útil de
seu cliente ser capaz de enviar informações através das quais seu servidor reconhece o cliente.
Mas, é claro, os cookies têm limitações.
Eles são um tamanho fixo, então eles não podem codificar muitas informações
sobre o cliente que seu servidor pode recuperar do cookie.
O cookie é usado apenas para lembrar o servidor sobre
qual cliente está enviando a solicitação.
Agora, se você quiser ter um mecanismo mais elaborado para rastrear informações sobre
um cliente, então, no lado do servidor, você pode configurar o que são chamados como sessões.
Agora, sessões é um mecanismo genérico que está disponível com qualquer servidor.
Em particular, analisaremos o próprio Express e
como o Express oferece suporte ao gerenciamento de sessões no lado do servidor.
A maneira como funciona é que a sessão do usuário está configurada no lado do servidor.
Portanto, esta sessão em si é uma combinação de um cookie e
um ID de sessão, e o lado do servidor rastreia informações
associadas a esse ID de sessão, ou indexadas por esse ID de sessão.
As informações da sessão em si podem ter qualquer
quantidade de informações sendo rastreadas no lado do servidor e indexadas por esse cookie.
Assim, quando um cliente envia uma solicitação sobre o servidor, em seguida, de dentro do cookie
o ID da sessão é recuperado e que é usado como um índice para o lado do servidor.
Por exemplo,
se você estiver usando um banco de dados do lado do servidor, esse índice será o índice primário
nesse banco de dados do lado do servidor específico que rastreia as sessões.
E assim, informações adicionais sobre essa sessão podem ser recuperadas e
usadas pelo servidor para tomar decisões sobre como
ele atende a solicitação do cliente de entrada.
Agora, por padrão, as sessões são armazenadas na memória no site do servidor.
Agora, obviamente, o que isso significa é que se seu servidor for reiniciado, sua memória
será apagada e assim todas as informações da sessão desaparecerão completamente.
Então, em vez disso, muitos servidores recorrerão ao
uso de alguma forma de armazenamento permanente onde as informações da sessão são rastreadas.
O armazenamento permanente no lado do servidor pode ser feito
através de algum tipo de armazenamento de arquivos.
Ou mesmo aproveitar o fato de que você já tem um banco de dados no lado
do servidor e armazenar as informações da sessão no lado do servidor.
Por exemplo, em seu próprio MongoDB.
Agora, no exercício que se segue, vamos olhar para o uso de um armazenamento de arquivos para
rastrear informações de sessão no lado do servidor.
Outro aspecto que você precisa prestar atenção é o fato de que, se você
estiver tendo uma implementação de servidor distribuído em que vários
servidores estão atuando como o servidor para atender a solicitação.
Em seguida, o servidor distribuidor deve ser capaz de acessar as informações da sessão.
Qualquer um desses servidores deve ser capaz de acessar as informações da sessão.
Portanto, você precisará de uma ferramenta de sessões de distribuidor no lado do servidor,
para permitir que você ofereça suporte a vários servidores replicados.
Especialmente isso é útil quando estamos tentando garantir a confiabilidade
da operação do servidor.
Agora, novamente, não vamos entrar em muitos detalhes sobre aqueles neste
curso em particular, vamos depender de entender basicamente como as sessões Express funcionam.
Vindo especificamente para o Express e
como o gerenciamento de sessões é suportado no Express. O
Express usa o middleware de sessão expressa que oferece suporte
ao uso de sessões em um servidor Express.
Agora você instala o middleware de sessões expressas.
E no exercício, vou usar o FileStore
como uma forma de armazenar permanentemente as informações da sessão.
E assim, também incluiremos o módulo de nó de sessão file-store que
nos permite usar os arquivos no lado do servidor para rastrear as informações da sessão.
Veremos os detalhes no exercício que se segue.
E então uma vez que fazemos isso sua sessão em si será configurado com o novo
servidor express declarando o middleware aqui como sessão que leva
um certo conjunto de opções como um parâmetro aqui.
As opções incluem o nome da sessão, então daremos o id da sessão para
a sessão específica.
E então você também fornecerá o segredo, uma chave secreta que é usada para
codificar o cookie assinado que será enviado para o lado do cliente.
E, em seguida, também informações adicionais incluindo SaveUnInitialized, que
será um sinalizador que é usado e também um sinalizador de resave que é usado.
Analisaremos alguns dos detalhes dessas opções no próximo slide.
Então, todas essas opções são especificadas aqui.
E se você é FileStore como o armazenamento permanente para suas sessões,
então vamos declarar que também nas opções de sessão lá.
Então é assim que nós iria configurar uma sessão no lado do servidor expresso
usando o Middleware de sessão expressa.
E o middleware de sessão expressa, quando o cliente envia essas informações,
isso será analisado no lado do servidor e
isso resultará em uma propriedade chamada sessão sendo adicionada ao objeto request.
Portanto, esta informação de sessão será acessível no
objeto de solicitação como req.session.
Assim, o req.session irá transportar informações adicionais sobre essa sessão específica
para esse cliente específico.
Agora, uma vez que esta sessão, solicitação de entrada é analisada pelo middleware de sessão,
a propriedade req.session será adicionada ao
objeto de mensagem de solicitação de entrada que expressa usa.
Assim, após a sessão é analisada, propriedade de sessão direta estará disponível e
podemos examinar isso também para verificar qual cliente enviou esta solicitação.
Quando eles configuram seu objeto de sessão no site do servidor,
como vimos, podemos configurar várias opções para esse site do servidor.
O cookie, as opções do cookie ID de sessão e o valor padrão para
o cookie serão como mostrado aqui, que é o caminho: '/',
HttpOnly: true, secure: false, maxAge: null.
Portanto, este será o valor padrão do cookie que será armazenado no pacote
e enviado para o lado do cliente como um cookie assinado.
E isso seria incluído em cada solicitação recebida do site do cliente.
Em seguida, o genid é a função que gera o ID da sessão.
O padrão é usar o UUID do próprio servidor como o ID geral.
Em seguida, o sinalizador de resave, se for verdadeiro, força uma sessão a ser salva novamente
na loja, mesmo que não seja modificada pela solicitação.
Às vezes, a solicitação de entrada pode
conter uma necessidade de modificar as informações da sessão no lado do servidor.
Assim, se a informação da sessão for modificada, terá que ser persistente.
Se não, então você não precisa persistir.
Mas se você definir o sinalizador de resave como true, mesmo que as informações
da sessão no servidor não sejam modificadas pela solicitação do cliente de entrada, ele ainda será resalvo.
A próxima bandeira que olhamos foi SaveUnInitialized.
Se isso for verdade, ele criará uma sessão recém-criada sem quaisquer modificações
a serem salvas do armazenamento de sessão.
Agora vamos definir isso como false por padrão, o que significa que só vamos
rastrear as sessões que estão autorizadas no servidor.
Agora, o segredo, como vemos, é a chave secreta que é usada para assinar o cookie,
e a própria loja especifica a instância de armazenamento de sessão que é usada.
O padrão é usar o armazenamento na memória.
Você pode especificar o armazenamento de arquivos ou o armazenamento Mongo para
armazenar essas informações de sessão e assim por diante.
Assim, uma vez que você especificar esta informação para o seu middleware de
sessão expressa, em seguida, a sessão será adequadamente configurada e assim será rastreada no lado do servidor.
Cada solicitação de cliente será então mapeada para as informações da sessão no
lado do servidor quando a solicitação do cliente é analisada pelo middleware de sessão expressa.
E o req.session será adicionado ao objeto de solicitação.
Com esta compreensão de cookies e sessões expressas,
vamos passar para o exercício onde vai olhar para como vamos fazer uso de cookies primeiro.
E então vamos ver como vamos fazer uso de sessões Express Express
dentro do nosso aplicativo Express REST API que temos trabalhado até agora.
[ MUSIC]