CORS error when trying to access supabase from a docker container

Hello,

I would like to dockerize a Svelte app that uses Supabase Auth. I am running Supabase CLI locally and the API url is available at

http://localhost:54321

http://localhost:54321

http://localhost:54321

http://localhost:54321

To access this url from within the Docker container I use the

http://host.docker.internal:54321

http://host.docker.internal:54321

http://host.docker.internal:54321

http://host.docker.internal:54321 url (https://docs.docker.com/desktop/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host)

This approach however produces a CORS error when trying to use Auth - see attached screenshot.

I could not find a

cors

cors

cors

cors parameter in the

config.toml

config.toml

settings file of Supabase CLI. How can I add/update CORS to include the

host.docker.internal

host.docker.internal

host.docker.internal

host.docker.internal origin?

In general, what is the recommended practice for using Supabase locally together with a dockerized web app?

Many thanks for the help!

Socal•1/11/24, 4:59 PM

is this local development?

Socal•1/11/24, 5:00 PM

are you using some kind of tunnel (ngrok or cloudflare tunnel or something else) to expose your callback endpoint to the internet?

did you add your internet available endpoint address to your supabase dashboard allowable addresses for callbacks?

Mr. OrangeOP•1/12/24, 9:26 PM

Hi @Socal, thanks for your reply.

Yes, I am running everything on my local machine - local development environment.

Supabase CLI runs directly on the host machine (MacOS), and the API url is available at the standard port:

http://localhost:54321

http://localhost:54321

The Svelte app runs inside a docker container, started with docker compose. In order for the Svelte app to access the supabase url (container --> host), I am using the special DNS name

host.docker.internal

host.docker.internal

, which resolves to the internal IP address used by the host. This is standard practice in docker containers.

For some reason though Supabase does not accept the incoming connection from the app in the docker container, and I get the above CORS issue.

I have tried adding the

http://host.docker.internal:54321

http://host.docker.internal:54321

to the auth.additional_redirect_urlsauth.additional_redirect_urls list of callback urls in the

config.toml

config.toml

file of Supabase CLI, but that didn't work.

Mr. OrangeOP•1/12/24, 9:28 PM

I tried to find some sort of way to change the Supabase Auth CORS settings, but I do not think this is possible. Just wondering what are other people doing when they want to use Supabase with dockerized apps..

Socal•1/12/24, 9:30 PM

did you adjust sveltekit cors as well?

Socal•1/12/24, 9:30 PM

is it svelte or sveltekit?

MMr. Orange Hi @Socal, thanks for your reply. Yes, I am running everything on my local mach...

Socal•1/12/24, 9:35 PM

if it's sveltekit you're going to need to turn off checkOrigin in the svelte.config.js file

        csrf: {
            checkOrigin: false
        }

        csrf: {
            checkOrigin: false
        }

Mr. OrangeOP•1/12/24, 9:35 PM

Thanks! I have already done this!

Mr. OrangeOP•1/12/24, 9:36 PM

In svelte.config.js, I have set config.kit.csrf.checkOrigin to false

Mr. OrangeOP•1/12/24, 9:36 PM

Hmm do you think the issue is on the Sveltekit side?

Socal•1/12/24, 9:37 PM

not if you have that set to false

Socal•1/12/24, 9:37 PM

just trying to get the easy stuff out of the way since it looks like you're running kubernetes and trying to have the servers in the clusters talk to each other

Socal•1/12/24, 9:38 PM

so if you have csrf turned off it's likley not a client side issue. are you able to connect to he postgres database via a different method other than your client? (db utility)

Mr. OrangeOP•1/12/24, 9:40 PM

No, I'm not running kubernetes. Just a simple Dockerfile with docker-compose. One container only, running the sveltekit app.

Socal•1/12/24, 9:40 PM

are you starting supabase via the supabase cli?

Mr. OrangeOP•1/12/24, 9:40 PM

Yes, when I run the Sveltekit app directly (outside docker) with npm run devnpm run dev and set the database url to

http://localhost:54321

http://localhost:54321

I am able to connect to the database, and use Supabase Auth (that's what I need).

Mr. OrangeOP•1/12/24, 9:41 PM

yep, I'm running supabase startsupabase start

Mr. OrangeOP•1/12/24, 9:41 PM

(thanks so much for looking into this)

Socal•1/12/24, 9:41 PM

why is this

http://host.docker.internal:54321

http://host.docker.internal:54321

instead of

http://localhost:54321

http://localhost:54321

Mr. OrangeOP•1/12/24, 9:43 PM

When running an app inside a docker container, localhost points to the app running inside the docker and not to the host machine (where Supabase CLI is running). So if I use localhost:54321localhost:54321 I get a connection error.

Mr. OrangeOP•1/12/24, 9:44 PM

This docker doc article covers connecting from a container to the host machine: https://docs.docker.com/desktop/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host

Mr. OrangeOP•1/12/24, 9:45 PM

The article recommends using

http://host.docker.internal:54321

http://host.docker.internal:54321

inside the docker container, which should connect to the service (supabase) running on the host.

Socal•1/12/24, 9:54 PM

i think i see what's happening

Mr. OrangeOP•1/12/24, 9:54 PM

I think there are two issues:
1) If I use

http://localhost:54321

http://localhost:54321

, then I am able to request a magic link with Supabase Auth (because this part runs on the client, in the browser, and the browser is able to see the locally running Supabase API url. However when I click the magic link, the server side authentication of the OTP fails, because that part runs on the backend server (which is inside the container), so it can't connect to the Supabase server.
2) If I use http://host.docker.internal:54330http://host.docker.internal:54330, then the browser tries to connect to this url but it doesn't exist.

Socal•1/12/24, 9:55 PM

in config.toml the additional_redirect_urls needs to be the full url that you're calling. example

http://host.docker.internal:54321/auth/v1/otp

http://host.docker.internal:54321/auth/v1/otp

Mr. OrangeOP•1/12/24, 9:55 PM

(I just tested a random invalid url, and got the same CORS error message, which means it's not necessarily a cors issue, it could be an unreachable server)

Socal•1/12/24, 9:55 PM

not that

Socal•1/12/24, 9:55 PM

whatever the full redirect url is

Socal•1/12/24, 9:55 PM

i can't see it from the error message

Mr. OrangeOP•1/12/24, 9:56 PM

Let me try~!

Socal•1/12/24, 9:56 PM

Socal•1/12/24, 9:56 PM

this url needs to be in the additional redirects

Mr. OrangeOP•1/12/24, 10:00 PM

I have added the full url in the additional_redirect_urls - didn't work. When I set the database url to

http://host.docker.internal:54321

http://host.docker.internal:54321

it's not even generating a magic link. I get the error as soon as I enter the email address in the login form.

Mr. OrangeOP•1/12/24, 10:00 PM

I think this is the reason...
CORS error when trying to access supabase from a docker container

Mr. OrangeOP•1/12/24, 10:01 PM

sorry I meant to link to this message:

I think there are two issues:
1) If I use http://localhost:54321, then I am able to request a magic link with Supabase Auth (because this part runs on the client, in the browser, and the browser is able to see the locally running Supabase API url. However when I click the magic link, the server side authentication of the OTP fails, because that part runs on the backend server (which is inside the container), so it can't connect to the Supabase server.
2) If I use http://host.docker.internal:54330, then the browser tries to connect to this url but it doesn't exist.

I think there are two issues:
1) If I use http://localhost:54321, then I am able to request a magic link with Supabase Auth (because this part runs on the client, in the browser, and the browser is able to see the locally running Supabase API url. However when I click the magic link, the server side authentication of the OTP fails, because that part runs on the backend server (which is inside the container), so it can't connect to the Supabase server.
2) If I use http://host.docker.internal:54330, then the browser tries to connect to this url but it doesn't exist.

Socal•1/12/24, 10:02 PM

sveltekit has a browser checker https://stackoverflow.com/questions/67808939/how-can-i-tell-whether-sveltekits-load-function-is-running-on-the-server-vs

Stack Overflow

How can I tell whether SvelteKit's "load" function is running on th...

I'm trying to do API calls in a SvelteKit page from the load function, but I don't want to proxy these calls with local endpoints because I want to keep the web server as light as possible.
What I ...

Socal•1/12/24, 10:04 PM

you can probably use that to help you out. or you can use the supabase auth helpers to help out on what is a client side supabase vs a server side supbase https://supabase.com/docs/guides/auth/server-side/migrating-to-ssr-from-auth-helpers?framework=sveltekit

Migrating to the SSR package from Auth Helpers | Supabase Docs

Step-by-step guide to migrating your app to the new SSR package

Mr. OrangeOP•1/12/24, 10:07 PM

Thank you! I'll check this out right now

Mr. OrangeOP•1/12/24, 10:07 PM

I appreciate your help and time very much!

Mr. OrangeOP•1/12/24, 10:09 PM

ok I actually figured it out!
I edited my MacOS /etc/hosts/etc/hosts file, and added the

host.docker.internal

host.docker.internal

url to point to localhost. Then set the database url to

http://host.docker.internal:54321

http://host.docker.internal:54321

, as I was doing before and it worked.

The browser (client side) was able to see the supabase url, and the backend was able to verify the OTP using this url.

Mr. OrangeOP•1/12/24, 10:10 PM

Thank you so much for your help and ideas!

CORS error when trying to access supabase from a docker container

Similar Threads

Similar Threads

Similar Threads