- Navios
- 22 de agosto de 2026 às 21:47 UTC
- Autor
- Kamo
- Enviar
- 0fc3aff
Nada no SecurityService já escreveu users.last login. A escrita viveu no serviço de autenticação aposentado e não foi transitado quando autenticação movida para o serviço de autenticação de usuário somente do JDBC, que lê e nunca escreve. A coluna era, portanto, NULL para cada usuário, e cada superfície mostrando-o ler "Nunca": os membros /conta e grades de membros da equipe, o chip de cabeçalho do perfil de membro, e a guia Login & Segurança. Nada errado em qualquer lugar, porque cada camada se comporta corretamente para um nulo. Selecioná- lo onde a chave única é cunhada em vez de onde a senha está Verificado. O OTK é o que realmente entrega a sessão ao navegador, então um o sign-in que pára no segundo fator provou uma senha, não uma identidade, e não deixa marca até que o fator seja atingido. Personagem e entrada como deliberadamente não carimbar: aqueles menta uma sessão e drives de administrador, e gravá-lo como o próprio login que eles nunca executaram em uma superfície de auditoria. /dispositivo/troca é um token de fundo atualizar que também lida com a mudança de org, então carimbá-lo seria transformar o valor em "última vez que o telefone telefonou para casa". O valor é LocalDateTime.toString() em UTC truncado para milissegundos, o offset-less shape app/lib/serverTime.ts já analisa; o lado web não precisava Mudança. Efeito colateral que vale a pena saber: isso faz com que o portão de placeholder em SecurityController A sério. Ele testa "nunca verificado E nunca assinado", e com last login sempre NULL a segunda cláusula foi sempre verdadeira, degenerando a verificação para !emailVerificado sozinho. As linhas existentes permanecem NULL até que cada usuário entre. Os logins nunca foram Gravado, por isso não há nada para preencher.