To localhost, or not [workaround]

I know this is not technically a RedwoodJS question…

It’s about how to use Supabase with Redwood, both while developing and also while deployed…

I have question about how to use the Dashboard → Settings → Authentication → Site URL & Additional Redirect URLs fields

I have, during development, used http://localhost:8910 in the Site URL field and everything has gone very well

I especially like how easy you’ve made it to attach a public.profile table to the auth.users table

But now that I’ve pushed my 1st deployment to Netlify, I don’t know what to put into the Site URL & Additional Redirect URLs fields

I’ve tried keeping http://localhost:8910 in the Site URL field, and adding the Netlify deployed app url in the Additional Redirect URLs field

And the App, when visited at the Netlify url, redirects lo localhost:8910 (which fails on my phone)

I’ve tried putting the Netlify deployed app url in the Site URL field, and putting http://localhost:8910 into the Additional Redirect URLs field

And the App, when visited at the localhost url, redirects to Netlify (which means I can’t write new code…)

I’m not sure how to proceed…

For Supabase development locally including authentication, have a look at the Supabase CLI

https://supabase.io/blog/2021/03/31/supabase-cli

It stands up the entire Supabase stack in Docker via a docker compose file: Kong, Postgres, Postgrest, Real-time, Storage, mailer and Auth.

You then point your Redwood app in development to the local urls.

Just note that if you have PG installed locally on the default 5432 port you should use a different one when setting up Supabase CLI

What’s nice is you get all the PG schemas for public, auth and storage and also since this is a db locally all normal Prisma migrate dev commands work just fine before you can deploy to Supabase hosted — like a proper staging or production environment.

This is great! I’m on the Supabase community board, and Subabase is aware of the problem and is working on a solution as of 13 days ago at least.

I’ll post this answer there - it’s going to generate some smiles I hope

Using the Supabase suggested postgres trigger to keep a public.users table in sync with the auth.users table works nicely. While prisma definitely did not like a trigger definition that pointed off into another schema, the solution still works ok for me.

Thanks (as always @dthyresson)
Al;