Authorization - #51
Merged
Merged
Conversation
…cation.getUser()`
Faltou um `return` no final do handler do endpoint de status que não
Padroniza o uso do caractere ` para envolver nomes de campos ou outros
…gin}` Após a introdução do `webserver` com o `origin` do serviço web, vários
Estes dois módulos estavam listados como dependência para rodar o
…ookie()` Estes dois métodos do componente `controller.js` estavam declarados como
Este commit conserta o formato da data que utilizei em um dos testes
…s/[username]` Depois de aplicar o filtro de saída que agora faz não devolver mais a propriedade `email` do `user`, eu simplesmente removi a expectativa deste valor ser retornado na resposta da API de todos os testes. E apesar de que isto continua válido, no teste de atualização de email ficou faltando a cobertura se a propriedade `email` foi atualizada de forma persistende no banco de dados. Então este commit busca o usuário no banco e verifica se de fato a informação foi alterada como deveria.
Antes estava sendo criado o objeto de router do `next-connect` e contra este objeto é que estava sendo "anexado" os métodos disponíveis para um certo endpoint na API (incluindo o `handler`) onde, depois disso, esse objeto de router era exportado como `default` do arquivo do controller. Mas agora com a refatoração deste commit, todo o export e encadeamento de métodos e handler acontece de uma só vez, pois fica mais limpo e direto de se ler o código. Isto é um tipo de refatoração que é muito bom de se fazer quando você tem uma cobertua boa de testes `E2E` 🙏
Aqui eu faço o método `orchestrator.createSession()` aceitar um objeto de `user` por inteiro (ao invés só do `id`) para ficar com a mesma interface pública de `orchestrator.activateUser()`.
… tests Os testes de `GET` do endpoint de status utiliza um usuário privilegiado e era um teste que estava passando mesmo sem ter as migrations executadas. Isto estava funcionando, pois numa bateria completa de `npm test`, algum outro teste já teria feito o trabalho de criar as tabelas, sendo que quando o teste era executado de forma isolada, naturalmente quebrava por não ter a tabela `user` (necessária para criar um usuário privilegiado). Então foi só questão de padronizar o hook principal para limpar o banco de dados e rodar as migrations igual ao restante dos outros testes.
Esta modificação tem impacto real apenas para navegadores mais antigos, antes de 2020 aproximadamente, porque os navegadores modernos já adotam `SameSite=Lax` por padrão. O `SameSite=Lax` faz o navegador ser mais criterioso na hora de enviar o cookie de sessão (ou qualquer outro cookie), principalmente quando a navegação ou a requisição foi iniciada a partir de outro site, por exemplo, algum hacker tentando interferir em um site que você esteja logado através de um outro site que ele tenha algum controle. De qualquer forma, mesmo o `SameSite=Lax` sendo o padrão em navegadores modernos, ainda assim faz sentido declarar ele no código de forma explícita porque deixa a intenção de segurança documentada, evita depender de comportamento implícito do navegador e abre as portas para decidirmos mais para frente adotar o valor `Strict` e entender as diferenças. Fora tudo isso, o impacto da mudança é mínimo e o ganho de clareza e previsibilidade compensa.
Nos testes sobre criar uma sessão válida, a propriedade `expires_at` do objeto de sessão é calculada na camada da aplicação, antes da persistência. Já a propriedade `created_at` é calculada depois, lá na camada do banco de dados, o que faz uma sessão não ter exatamente 30 dias de expiração em milissegundos que seriam `2592000000` e ficando então com valores muito próximos como `2591999991`, por exemplo, que são 30 dias menos 9 milissegundos. Os testes atuais já tentavam compensar esta diferença ao zerar os segundos das datas envolvidas, mas é uma alternativa que possui um furo dependendo de algumas condições como o virar do minuto. Tentei pegar este comportamento para mostrar em uma aula, mas não consegui e isto estava me agoniando ao pensar que algum aluno poderia ver o seu CI quebrando e não entender o motivo. Então para já evitar esta situação daqui para frente e depois de sugestões de vários alunos, optei por adicionar uma margem de erro de 5 segundos entre o que é esperado (30 dias exatos de expiração) e o que o objeto de sessão de fato possui de tempo de expiração.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Closed
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.