Sistema fazendo logout assim que acessa a dashboard, mesmo havendo sucesso no login
-
Situação
No GT do cliente estava ocorrendo um problema estranho, assim que o sistema me direcionava para a dashboard da aplicação, ele também fazia o logout automático, impedindo que eu usasse o sistema.
Na lista de requests havia o seguinte:- GET v1/requestExemplo.....
- GET v1/notificacoes....
- GET v1/requestExemplo2....
- POST v1/logout.....
Note que o logout acontece logo após a primeira request da aplicação depois de ter sido feita a coleta das notificações....
Cenário de configuração do cliente
O cliente roda Ponto, Akita e GT na mesma infra. Ponto e Akita usam insoft-auth e insoft-notification-api conectados na base ponto7, enquanto GT a princípio usa insoft-auth e insoft-notification-api conectados na base gtsoft.
Todavia, após análise foi visto que nos arquivos de configuração do gtsoft (back e front), a url da insoft-notification-api está apontando para o endereço onde está rodando a insoft-notification-api do Ponto e Akita.
Essa configuração faz o token criado na base do GT ser invalidado pelo insoft-auth do insoft-notification-api do Ponto (por conta desse token não estar disponível na base do Ponto).
Assim que o gtsoft-api recebe uma request com um token inválido, ele devolve um header na response indicando ao frontend que é necessário deslogar pois o token é inválido.Correção
Após colocar nos arquivos de configuração do GT a url do insoft-notification-api que é de fato do GT, o logout deixou de ocorrer. Essa alteração no arquivo exige a reinicialização do gtsoft-api caso for feita alteração no application.yml.
Observação
Em algumas ocasiões onde o cliente usa proxy reverso, pode ser que a config de url do insoft-notification-api precise estar com localhost+porta ao invés do nome do domínio, no caso de estar no mesmo server que a aplicação final. Isso vai depender da configuração do proxy, mas no geral parece estar sendo comum a necessidade de usar localhost ao invés do domínio mascarado.