Loop de redirecionamento no login do Lovable: prompts para corrigir com segurança

Resolver um loop de redirecionamento no login do Lovable exige identificar exatamente qual etapa falhou: criação de sessão, tratamento de callback, proteção de rotas ou acesso aos dados do usuário. Peça ao Lovable para inspecionar esse caminho antes de mexer no código, aprovando depois um único ajuste pontual. Aqui você encontra prompts prontos para copiar, um checklist de testes e um planejamento de depuração feito para evitar tentativas repetidas.

O escopo faz toda a diferença. O foco aqui são aplicações que ficam alternando sem parar entre o login e uma página protegida, ou que voltam para o login logo após a autenticação. Um e-mail de cadastro que não chega, um provedor de identidade fora do ar ou uma senha errada exigem caminhos de investigação bem diferentes.

Por que seu app no Lovable não sai da tela de login

O loop de redirecionamento é só o sintoma, nunca o diagnóstico. O navegador pode até piscar no dashboard por um instante, mas isso não significa que o app conseguiu restaurar a sessão por completo.

Muitos fluxos de autenticação precisam de pelo menos três estados:

• Loading: o app ainda não determinou se existe uma sessão ativa.
• Authenticated: há uma sessão válida e pronta para uso.
• Unauthenticated: a checagem terminou e nenhuma sessão foi encontrada.

Se o route guard trata o estado de loading como unauthenticated, o redirecionamento acontece antes da hora. Essa é uma causa plausível, mas não resolve qualquer caso. Colocar um spinner na tela não conserta uma URL de callback errada nem uma consulta rejeitada no banco de dados.

Outra falha muito parecida ocorre quando a autenticação funciona, mas a busca pelo perfil do usuário falha. O app confunde dados ausentes de perfil com ausência de sessão e joga o usuário de volta ao início. Essa distinção é crucial: mexer no código de login deixará o problema real intacto se a raiz estiver no banco.

Use a tabela abaixo para definir a primeira linha de investigação, e não para cravar a causa de imediato:

| O que você observa | O que inspecionar primeiro | O que não alterar às cegas | |---|---|---| | Atualizar a página protegida joga você para o login | Inicialização da sessão e timing do route guard | O auth provider inteiro | | Login por senha funciona, OAuth falha | Configurações do provedor, callback e URLs de redirecionamento | Lógica do login por senha | | Funciona no preview, falha no domínio publicado | Variáveis de ambiente e URLs de redirecionamento autorizadas | Permissões do banco de dados | | Login dá certo, mas a requisição de perfil falha | Erros de query, criação de perfil e policies de acesso | Persistência da sessão | | Apenas sessões existentes no navegador falham | Estado da sessão armazenada e comportamento de refresh | Dados da conta de todos os usuários | | Login e dashboard alternam sem parar | Redirecionamentos concorrentes e subscriptions de auth | Rotas não relacionadas ou layout da página |

Se o app utiliza autenticação do Supabase, o gerenciamento de sessões e a configuração de redirecionamento precisam entrar na análise. Caso use outro backend, ajuste os prompts para essa tecnologia. Nunca peça ao Lovable para trocar de provedor como atalho de correção.

Regra prática: examine a fronteira exata onde ocorre a falha, em vez de fuçar em cada componente que menciona o usuário.

Reúna evidências antes de queimar mais créditos

Separe de 10 a 15 minutos para mapear uma reprodução clara do erro. Essa estimativa de tempo compensa muito mais do que mandar outro comando vago do tipo "conserte o login".

1. Registre o ambiente exato. Anote se o erro acontece no preview do Lovable, na URL de publicação ou em um domínio personalizado. Especifique o navegador e a forma de login. Se a falha só ocorre com o Google login no domínio próprio, detalhe isso logo no início.

2. Descreva o passo a passo mais curto de reprodução. Um exemplo simples: acessar `/dashboard` sem login, ser redirecionado para `/login`, enviar credenciais válidas, ver a tela de `/dashboard` por um segundo e cair de novo em `/login`. Use as rotas reais do seu projeto.

3. Compare uma sessão limpa com uma existente. Faça o teste em uma janela anônima. Se funcionar por lá, você tem indícios claros sobre o estado da sessão local, o que não significa que limpar o storage seja a solução definitiva. Mantenha a sessão problemática aberta até registrar todo o comportamento.

4. Procure a primeira falha relevante. Abra o DevTools do navegador e olhe as abas Console e Network. Marque a opção de manter os logs ativos durante a navegação. Encontre a primeira requisição que falhou, seja de callback, autenticação ou perfil, em vez de se perder no último erro da cascata.

Uma resposta 401 ou 403 aponta um caminho, mas não traz o diagnóstico completo. Registre o endpoint, o status HTTP e a mensagem de erro limpa. Nunca cole senhas, cookies, access tokens, refresh tokens, headers de autorização ou dados confidenciais nos seus prompts.

5. Identifique o último estado estável. Lembre-se da alteração mais recente: uma nova rota protegida, um domínio personalizado, uma etapa de onboarding ou um novo campo no perfil. Guarde um ponto de restauração do código pelo histórico ou pelo GitHub. Restaurar o código nem sempre reverte migrações de banco ou regras externas de autenticação.

Em seguida, preencha este resumo:

```text Bug: O login redireciona de volta para a tela de login. Ambiente: [preview / URL publicada / domínio personalizado] Backend de auth e método: [backend; senha / OAuth / magic link] Resultado esperado: [destino e estado visível] Sequência real de rotas: [rota -> rota -> rota] Passos para reproduzir: [etapas numeradas] Resultado na janela anônima: [resultado] Resultado na sessão existente do navegador: [resultado] Inventar explicações só atrapalha.

Mantenha esse resumo anexado aos próximos pedidos. Você pode conferir nossa biblioteca de prompts para outras demandas, mas resista à tentação de misturar o conserto de autenticação com redesign ou novos recursos.

Prompts prontos para uma correção direcionada de auth

Envie estes prompts em sequência. Eles funcionam como filtros de decisão, não como um pacote para disparar de uma só vez. Se a primeira inspeção apontar erro no carregamento de dados do dashboard em vez de login, siga essa pista.

Prompt 1: Inspecionar sem alterar o código

Comece pedindo apenas uma análise técnica. Se a interface do Lovable tiver um modo de planejamento ou discussão, ative essa opção, mas reforce o limite na mensagem. O prompt não impede o modelo de tentar agir por conta própria, portanto acompanhe de perto o que ele faz.

```text Investigue este loop de redirecionamento no login. Não edite arquivos, configurações, policies do banco de dados nem schemas por enquanto.

[COLE AQUI O RESUMO DO BUG PREENCHIDO]

Mapeie o fluxo de autenticação no projeto atual:

1. Onde a sessão é inicializada e atualizada.
2. Como os estados de loading, authenticated e unauthenticated se diferenciam.
3. Quais guards e effects disparam a navegação.
4. Como o callback de login é concluído, se aplicável.
5. Se falhas de perfil ou onboarding disparam redirecionamento para o login.

Aponte os arquivos e funções relevantes. Liste as causas mais prováveis com base nas evidências. Separe fatos observados de hipóteses. Se não for possível verificar uma configuração de runtime ou log, informe.

Sugira o teste de diagnóstico mais direto para a próxima etapa. Não implemente nada ainda. ```

Uma resposta útil cita arquivos específicos, condições lógicas e pontos cegos de informação. Dizer que "a autenticação está desconfigurada" não ajuda em nada. Querer reescrever todo o sistema de login antes de investigar também não.

Prompt 2: Tirar uma dúvida pontual

Recorra a este prompt quando a primeira análise deixar duas hipóteses em aberto. Substitua os campos entre colchetes pelo dilema específico.

```text Precisamos diferenciar [hipótese A] de [hipótese B]. Não aplique uma correção definitiva ainda.

Proponha um único teste de diagnóstico e explique o significado de cada resultado possível. Dê preferência aos logs existentes e ao DevTools.

Se for necessário adicionar logs temporários no código, mostre o diff proposto antes para aprovação. Registre apenas nomes de estados, timestamps e rotas. Nunca exponha tokens, cookies, credenciais ou dados pessoais de perfil. Não altere a navegação enquanto estiver medindo o comportamento.

Inclua instruções de remoção para qualquer instrumentação temporária. ```

Isso evita um tropeço frequente: mudar a lógica do app enquanto você ainda tenta entender o que a versão anterior fazia. A abordagem também deixa o pedido seguinte bem mais cirúrgico.

Prompt 3: Corrigir apenas a causa confirmada

Com as evidências apontando para uma falha comprovada, autorize uma implementação contida. Estabeleça os limites no comportamento esperado, e não na exigência arbitrária de mexer em um único arquivo.

```text Implemente uma correção mínima para esta causa comprovada: [CAUSA E EVIDÊNCIAS]

Escopo permitido: [arquivos ou subsistema em questão]. Mantenha o backend de auth atual, métodos de login, rotas, layout e qualquer comportamento não relacionado do app.

Não desative controles de acesso, não adicione dependências, não faça migrações de schema e não refatore código fora do escopo. Se a solução exigir mudanças maiores, pare e explique o motivo antes de continuar.

Requisitos:

• Não redirecione apenas porque a inicialização da sessão está pendente.
• Diferencie ausência de sessão de falhas no carregamento de perfil ou onboarding.
• Mantenha os redirecionamentos corretos de logout e de usuários deslogados.
• Não insira delays arbitrários com timeouts para mascarar race conditions.

Após a alteração, liste os arquivos modificados, explique a mudança de comportamento e detalhe os testes executados. Indique com clareza quais testes não foram rodados. ```

Mantenha apenas as exigências ligadas ao seu diagnóstico. Se o problema for uma configuração de callback externa, solicite os ajustes exatos no painel do serviço e as validações necessárias, em vez de forçar alterações no código.

Um atraso arbitrário de dois segundos é uma péssima saída para problemas de sincronia de estado. Ele pode disfarçar o erro no seu computador e quebrar tudo de novo no celular de quem usa uma conexão mais lenta.

Prompt 4: Revisar regressões de autenticação

Fazer o login funcionar é obrigatório. Mas não basta.

```text Revise a correção de autenticação em comparação com a versão anterior. Não faça novas alterações durante esta revisão.

Verifique se:

• Conteúdo protegido ficou acessível para usuários deslogados.
• Redirecionamentos acontecem antes da conclusão da inicialização da sessão.
• Existem subscriptions duplicadas ou effects de navegação em conflito.
• Falhas de perfil estão sendo tratadas erroneamente como falta de sessão.
• Houve quebra no logout, em links diretos ou na atualização da página.
• Restaram logs temporários ou dados sensíveis expostos no código.

Separe resultados confirmados, apontamentos de code review e testes que ainda precisam de validação manual. Se houver testes automatizados, execute os que forem pertinentes e mostre a saída real. ```

Não se contente com respostas vagas como "todos os testes passaram" sem conferir o que de fato rodou. Uma simples leitura de código não valida as configurações ativas no painel de OAuth se ninguém as checou diretamente.

Valide a correção e controle os custos de depuração

Reserve entre 15 e 25 minutos para o diagnóstico, 10 a 20 minutos para um patch pontual e de 15 a 25 minutos para a validação. Essa faixa de 40 a 70 minutos serve para planejar problemas isolados, não como promessa de prazo. Instabilidades no provedor, envio de e-mails e reparos no banco de dados costumam demorar mais.

Execute este checklist tanto no ambiente de preview quanto no app publicado:

• [ ] Um visitante deslogado não consegue abrir páginas protegidas.
• [ ] O login bem-sucedido leva ao destino correto sem saltos indesejados.
• [ ] Atualizar a página protegida mantém a sessão ativa.
• [ ] Acessar uma URL protegida diretamente funciona para quem está autenticado.
• [ ] O logout bloqueia imediatamente o acesso a conteúdos restritos.
• [ ] Credenciais incorretas exibem uma mensagem útil em vez de prender o app em loop.
• [ ] Todos os métodos de login disponíveis foram validados individualmente.
• [ ] Dados de perfil ausentes ou inacessíveis recebem o tratamento adequado.
• [ ] Logs temporários foram removidos e o diff não traz alterações fora de escopo.

Faça testes usando contas descartáveis. Jamais relaxe as regras de segurança em produção apenas para forçar um resultado positivo nos testes.

Para não estourar seus créditos, adote um teto operacional: uma inspeção, um teste de desempate se houver dúvida, um patch e uma revisão. Isso delimita o número de comandos, mas não significa que vai custar exatamente quatro créditos. O consumo real depende das regras de cobrança do Lovable e da complexidade do trabalho.

Acompanhe o saldo na sua conta antes e depois de cada rodada. Apenas para ilustrar: se o custo efetivo fosse de US$ 0,20 por crédito e o processo gastasse 10 créditos, o custo ficaria em US$ 2. Esses valores são hipotéticos. Consulte o guia de preços do Lovable e o painel da sua conta para checar as tarifas oficiais.

Se dois patches seguidos não mudarem o comportamento do sistema, pare de editar. Reavalie o diagnóstico ou restaure a versão do código que funcionava, separando com clareza o que é código do que são mudanças de banco ou de painel. Mandar outro prompt genérico não vai resolver nada.

Documente os passos de reprodução, a causa raiz, o diff final e os testes executados. Esse pequeno histórico de incidente ajuda muito mais no futuro do que comemorar um "consertado" sem saber como. Nossos artigos sobre build e operações aprofundam as etapas de release e deploy.

Por que o login funciona no preview, mas quebra no meu domínio?

Cada ambiente pode ter origens, URLs de redirecionamento ou configurações de backend diferentes. Compare a URL de callback que falhou e as opções de autenticação com o endereço final de produção. Confira os requisitos específicos de cada provedor em vez de achar que o sucesso no preview garante a configuração correta no ar.

Devo desativar o row-level security para arrumar o login?

Não faça isso. Se o seu backend usa row-level security, desligar essa proteção pode vazar dados de ponta a ponta sem resolver a raiz do problema de autenticação. Confirme primeiro se a sessão realmente existe e descubra qual query está falhando. Ajuste a consulta específica, a criação de perfil ou a policy de acesso sem comprometer as barreiras de autorização.

Quantos créditos do Lovable custa resolver um problema de auth?

Não existe um valor fixo. Monitore o consumo real na sua conta e mantenha cada prompt restrito a uma tarefa clara. Um resumo com evidências bem estruturadas e um patch focado diminuem o retrabalho, mas não oferecem garantias mágicas de acerto na primeira tentativa nem um custo pré-determinado em créditos.