Description
alesAuth e alesUser fazem parte do sistema de autorização que o frontend vai implementar na comunicação com o backend.
Como é agora
Atualmente apenas a autenticação acontece no Auth0, com todo o processo de autorização e permissões vivendo no backend. Isso permite muito mais flexibilidade e controle sobre quais endpoints o usuário tem permissão pra ver e quais roles o usuário tem.
Porém, isso faz com que o frontend tenha essencialmente dois "tipos" de dados de usuário.
Um é o user simples que contém os dados do usuário dentro do Auth0. Esses dados são as coisas que vieram da rede social, os dados do pré-cadastro e as contas que o usuário tem linkadas.
Outro é o alesUser, o usuário que existe no banco de dados do Django. Esse usuário contém os dados dentro do banco, como escola, série, matérias que o aluno faz, etc.
Para um aluno ter um user tudo que ele tem que fazer é clicar em "inscrever-se" na página principal. Quando o Auth0 retorna, o aluno já possui seus dados em user. alesUser é diferente e só existe para usuários que foram até o final do processo de pré-cadastro (veja #8). alesUser também existe para usuários finais que já fizeram a confirmação presencial de cadastro, mas com dados extras (dados de matérias, guardiões, perfil, etc).
Problemas
- Não está clara a diferença entre o
alesUserapós pré-cadastro e após confirmação presencial do cadastro (usuários finais). - Flow que o frontend usa para pegar esses dados e verificar as permissões é confuso.
Possíveis soluções
Não criar um alesUser até o usuário virar usuário final
Usar uma flag no Auth0 para marcar que o usuário já enviou seu pré-cadastro. Podemos usar a API de pesquisa do Auth0 para filtrar e encontrar o usuário durante o cadastro presencial.
Só criamos o alesUser quando o cadastro presencial for completado e aí passamos todos os dados do formulário para o servidor.
Reconstruir o flow de autorização(alesAuth)
Flow atual é uma série de middlewares do Nuxt que são executados quando a página carrega, injetando vários métodos no this.$auth e coletando os dados do usuário.
Também há um middleware que é executado em cada navegação que procura por uma chave no SFC chamada alesUser que diz se usuários com (ou sem) alesUser podem ver aquela tela.
Simplificar isso com apenas um middleware que também consegue testar permissões e roles do usuário.