When a Lovable app's Supabase login is not working, name the failed step first. The provider might reject sign-in. Authentication might finish but return to the wrong address. The app might lose the resulting session. Or the user may be signed in correctly and still lack permission to read a record.

Those are different problems. Collect the public URL, backend, test user and time, then follow the journey in order. Use a disposable account and redact tokens from any notes or screenshots you share.

Confirm which backend the project uses

Lovable Cloud and a separately connected Supabase project have different management paths. Identify the current backend before searching for configuration in your personal Supabase dashboard. Supabase's backend identification guide explains how to distinguish them.

This article's Supabase configuration checks apply when you control that connected project. Follow the managed backend's current controls and documentation when your project uses Cloud instead. Do not switch backends as an unexplained troubleshooting shortcut.

Step 1: was sign-in accepted?

Capture the actual sign-in result. Record whether the app requested email confirmation, rejected a credential, returned a provider error or failed to send a request. Keep the original error so a later change can be tested against the same case.

If sign-in itself was rejected, a change to the post-login page does not resolve it. Compare the specific error with Supabase's auth troubleshooting index. Avoid changing several unrelated settings at once: you need to know which change affected the result.

Step 2: did the user return to the intended URL?

For a connected Supabase project, compare the requested return destination with the configured allowed redirects and default Site URL. Supabase uses those settings for relevant authentication flows. Its guidance recommends exact production destinations while supporting broader patterns for development and previews. Check the redirect configuration reference for your flow.

A preview passing does not establish that the published domain is configured. Write down the actual address reached after the return and compare it with the address your user should reach. Include the path and environment rather than only the hostname.

Step 3: does the next request carry the intended session?

Follow the first protected request after returning to the app. Compare what the application believes about the current user with what the server receives. A successful sign-in screen and an authenticated server request are separate observations.

Inspect the session handling appropriate to your client and framework rather than copying a cookie change from a different stack. Supabase describes the session lifecycle. Record the boundary where identity disappears, expires or is rejected.

Step 4: is this actually a record-permission problem?

If the server recognises the user but returns no permitted record, inspect ownership and authorisation. Sign-in establishes identity; it does not imply access to every row. Test the intended operation with two disposable accounts and a known sample record.

For a Supabase-backed data request, use its RLS reference to review the relevant policies and roles. Do not use a privileged server credential in browser code to make the symptom disappear.

A local example that separates the outcomes

The downloadable fixture contains a tiny HTTP server and fixed, fictional test identities. A request without a session receives 401. The sample record's owner receives 200 and the record. The other test client receives 403 for that same request. The checks are enforced by the handler, independently of a visible button.

Run it with Node 22 or later:

node --test app-repair-proof.mjs

See the recorded results. This is not a Supabase integration or production login implementation. It demonstrates why absent identity and insufficient permission deserve different diagnoses; it does not prove which one affects your project.

Retest the whole journey after the change

Start from the published URL without the old session. Complete the relevant confirmation or provider return, load the protected screen and perform the intended data operation. Sign out and repeat. Then test a different account against the first account's private sample.

Record the version, steps and outcomes. A passing redirect check does not close a failing read, and a working administrator account does not cover a new customer's experience.

For records that disappear after refresh, use the save-and-read guide. For a project-specific review, see help finishing a Lovable app or describe the stage that fails.