DEV Community: FixLoop

Lovable login works in preview, breaks in production: the 3 redirect lists

FixLoop — Sun, 18 Oct 2026 17:04:15 +0000

Login works on the Lovable preview. You publish, or put a custom domain in front, and now sign-in loops, drops you on localhost:3000, or comes back with no session. The React didn't change. The host did.

Supabase Auth only sends the browser back to URLs it already trusts. Preview was on that list. Production wasn't.

What it looks like

Preview: Google / GitHub / magic link works. Production: spinner, then the login page again.
After OAuth you land on http://localhost:3000 or the old *.lovable.app preview host.
The address bar ends in #error=... or error_description=Unsupported%20redirect.
Google shows Error 400: redirect_uri_mismatch naming a URL you don't recognize.
Confirm / reset emails open the preview app, or 404 on the live domain.

Test in a private window on the live origin. Preview cookies will lie to you.

There are three lists, not one

Most people paste the production URL into one box and call it done.

Supabase Site URL (Authentication → URL Configuration). The default redirect when your code doesn't pass redirectTo. Magic links and password resets use it. A new project starts at http://localhost:3000.
Supabase Redirect URLs (same page). The allowlist. Every redirectTo must match it, or Auth quietly ignores it and uses Site URL. That's how you "set production" and still bounce to localhost.
The OAuth provider's Authorized redirect URI (Google Cloud, GitHub). This is not your app. It's Supabase's callback, https://YOUR_PROJECT.supabase.co/auth/v1/callback. Publishing the Lovable app doesn't change it. Getting it wrong gives redirect_uri_mismatch at the provider, which looks like a Lovable bug.

On a connected Supabase project, the first two live in the Supabase dashboard, not the Lovable chat. (Lovable Cloud, the built-in backend, is configured in Lovable instead.)

The fix

Site URL = the live origin, e.g. https://myapp.com (or your *.lovable.app host if that's what's published). Leave preview out of it, since it's the default for emails.

Redirect URLs: add every origin you actually use. ** matches across /:

https://myapp.com/**
https://myapp.com/auth/callback
https://*.lovable.app/**
http://localhost:5173/**

Whatever path your code passes as redirectTo must be covered. A trailing-slash mismatch is enough to fall back to Site URL.

Provider console (Google / GitHub): JavaScript origins get your app's origin. Authorized redirect URIs get the Supabase callback copied from Authentication → Providers. Don't put https://myapp.com/auth/callback there: Google returns to Supabase, and Supabase returns to your app.

redirectTo in code: hardcoding the preview host is how production "randomly" returns to preview. Use the current origin:

const redirectTo = `${window.location.origin}/auth/callback`;

const { error } = await supabase.auth.signInWithOAuth({
  provider: "google",
  options: { redirectTo },
});

Same for resetPasswordForEmail and signInWithOtp. If you customized email templates, {{ .SiteURL }} always points at Site URL; use {{ .RedirectTo }} when the link should follow what you passed.

60-second checklist

Private window, live hostname.
Site URL is production, not localhost or only the preview host.
Redirect URLs cover production (plus /auth/callback if you use it); preview can stay as a wildcard.
Provider redirect URI is https://YOUR_PROJECT.supabase.co/auth/v1/callback.
redirectTo is built from window.location.origin.
Read the error / error_description in the URL fragment on the landing page. Auth still redirects on failure; the reason is in the hash.

Full guide

The longer version with source links and an FAQ (Site URL vs Redirect URLs, "I set Site URL, why localhost?", Lovable vs Supabase settings) is here:

https://fixloop.dev/guides/lovable-login-preview-vs-production

If sessions exist but saves silently do nothing, that's RLS, not redirects. I wrote up a 5-minute check for that.

I run FixLoop. There's a free scan for leaked keys and missing headers, and we fix broken Lovable/Supabase apps for a fixed price. No fix, no pay.

Is my Supabase database public? A 5-minute check with the anon key

FixLoop — Sat, 17 Oct 2026 20:09:09 +0000

If you shipped a Lovable (or any Supabase) app, your anon key is in the browser. That's fine, it's supposed to be. The real question is different: can a stranger read your tables with that key and no login?

If Row Level Security is off on a table that still has grants to anon, the answer is yes. Here's a 5-minute check you can run on your own project.

Why the anon key isn't the leak

The anon key is a public JWT. Postgres then decides what it can do in two layers:

Grants decide whether anon can SELECT / INSERT / UPDATE / DELETE the table at all.
RLS decides which rows survive that grant.

RLS off means the second layer never runs. If anon also has a grant (the old default on public tables), every row is reachable from the REST endpoint. A policy of using (true) is the same hole with RLS "on": the dashboard badge looks fine, the table is still public.

The check

Open your live app in a private window, DevTools → Network, filter rest/v1. Grab the project host (abcdefghij.supabase.co), a table name from the path, and the apikey header from a signed-out request. Never use the service_role key for this (or anywhere in the client).

curl "https://YOUR_PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=5" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

No cookies, no session. If this returns user data, anyone can do it too.

Reading the result

200 + rows: anon can read the table. RLS is off or a policy allows anonymous SELECT. Fix this first.
200 + []: there's a SELECT grant but no rows passed RLS (or the table is empty). Retry on a table you know has data. If the signed-in app shows rows and anon still gets [], you're probably fine.
401: bad or truncated key. This does not mean the table is private.
403 / 42501: anon has no grant, so the request never reaches RLS. After Oct 30, 2026 this shows up a lot on new tables (why).
404 / PGRST205: wrong table name. Use the one from the network tab.

The safe fix

Turn RLS on and scope policies to auth.uid(). Don't "fix" an open table by granting more.

alter table public.your_table enable row level security;

create policy "select own rows" on public.your_table
for select to authenticated
using (auth.uid() = user_id);

create policy "insert own rows" on public.your_table
for insert to authenticated
with check (auth.uid() = user_id);

grant select, insert, update, delete on table public.your_table to authenticated;

Don't do any of these:

GRANT ALL ON ALL TABLES IN SCHEMA public TO anon;
any grant to anon while RLS is off
using (true) on a table with private rows
the service_role key in frontend env

In Lovable, put the same rules in your project instructions so the next migration doesn't recreate the hole.

Full guide

The longer version with the browser-console variant, a checklist, and an FAQ (should I rotate the anon key? Lovable says RLS is on, can it still be public?) is here:

https://fixloop.dev/guides/is-my-supabase-database-public

I run FixLoop. There's a free scan for leaked keys and missing headers, and we fix broken Lovable/Supabase apps for a fixed price. No fix, no pay.

Supabase Oct 30: why new tables get 42501 (and how to fix grants + RLS)

FixLoop — Sat, 17 Oct 2026 17:14:20 +0000

If you just created a table in Lovable, turned on RLS, wrote policies, and the app still returns permission denied for table, this is the one.

Starting October 30, 2026, existing Supabase projects stop auto-granting privileges on new tables in the public schema. The table is there. The policies are there. The Data API still cannot see it.

Source: Supabase changelog · Securing your API

What it looks like

The request fails with Postgres error 42501. PostgREST (the Data API behind supabase-js) sends something like:

{
 "code": "42501",
 "message": "permission denied for table your_table",
 "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}

Typical setup: a Lovable-created table, RLS enabled, policies that should allow the row, and it still fails. Old tables keep working. Only the new one fails.

The hint names the missing grant. It is not a recommendation to copy blindly. Read it, then grant only what that role should have.

Grants vs RLS

Postgres runs two checks, in order:

Grants decide whether a role can touch the table at all (SELECT, INSERT, UPDATE, DELETE).
Row Level Security decides which rows that role can see or change.

If the grant is missing, RLS never runs. That is why "I have policies" does not fix 42501.

Until now, a new table in public automatically received select/insert/update/delete for anon, authenticated, and service_role. RLS was the only gate. New projects already dropped that default. On October 30 it applies to every existing project too.

Existing tables keep their grants. Direct Postgres connections are not affected. This is a Data API change: REST, GraphQL, and the client libraries.

The fix

Put grants in the same migration as the table, RLS, and policies. Least privilege, not GRANT ALL.

alter table public.your_table enable row level security;

-- signed-in users: the operations your app actually uses
grant select, insert, update, delete on table public.your_table to authenticated;

-- server code / Edge Functions using the service_role key
grant select, insert, update, delete on table public.your_table to service_role;

-- only if signed-out visitors should read this table
-- grant select on table public.your_table to anon;

Leave anon with nothing unless the table is meant to be public. Skip GRANT ALL ON ALL TABLES IN SCHEMA public - that also opens tables where RLS was never turned on.

If you already see 42501, check who has what:

select grantee, privilege_type
from information_schema.role_table_grants
where table_schema = 'public'
 and table_name = 'your_table';

Tell Lovable to include grants

Paste this into project instructions / Knowledge before the next migration:

When you create or change a Supabase table, put all of this in the same migration: CREATE TABLE, ENABLE ROW LEVEL SECURITY, CREATE POLICY, GRANT to authenticated and service_role, and GRANT SELECT to anon only if signed-out users should read it. Do not use GRANT ALL. Do not skip grants because RLS is on.

Full checklist + FAQ

The longer version with the Lovable paste block, checklist, and FAQ lives here (canonical):

https://fixloop.dev/guides/supabase-oct-30-grants-change

I run FixLoop - we fix broken Lovable/Supabase apps for a fixed price. No fix, no pay.