Unable to log in (Cross-Origin Request Blocked)

[a-dahm]

I am trying to set up Ganymede on a server in my local network. (It's a basic home network, so no proxy or other network restricting shenanigans)

I am able to start all the containers and do not get any errors in any container logs (with "debug": true in my config.json). However, when I visit the frontend and try to log in, nothing happens. Looking at the devtools console shows the following error messages:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://192.168.178.55:4801/api/v1/auth/login. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 204.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://192.168.178.55:4801/api/v1/auth/login. (Reason: CORS request did not succeed). Status code: (null).

I've looked at other relevant issues that were submitted in the past but could not come up with a solution.

My docker-compose.yml looks like this:

version: "3.3"
services:
  ganymede-api:
    container_name: ganymede-api
    image: ghcr.io/zibbp/ganymede:latest
    restart: unless-stopped
    depends_on:
      - ganymede-temporal
    environment:
      - TZ=[...]
      - DB_HOST=192.168.178.55
      - DB_PORT=4803
      - DB_USER=ganymede
      - DB_PASS=ganymede
      - DB_NAME=ganymede-prd
      - DB_SSL=disable
      - JWT_SECRET=SECRET=SECRET
      - JWT_REFRESH_SECRET=SECRET
      - TWITCH_CLIENT_ID=[...]
      - TWITCH_CLIENT_SECRET=[...]
      - FRONTEND_HOST=http://192.168.178.55:4800
      # OPTIONAL
      # - OAUTH_PROVIDER_URL=
      # - OAUTH_CLIENT_ID=
      # - OAUTH_CLIENT_SECRET=
      # - OAUTH_REDIRECT_URL=http://IP:PORT/api/v1/auth/oauth/callback # Points to the API service
      - TEMPORAL_URL=192.168.178.55:7233
      # WORKER
      - MAX_CHAT_DOWNLOAD_EXECUTIONS=5
      - MAX_CHAT_RENDER_EXECUTIONS=3
      - MAX_VIDEO_DOWNLOAD_EXECUTIONS=5
      - MAX_VIDEO_CONVERT_EXECUTIONS=3
    volumes:
      - /media/secondary/ganymede/vods:/vods
      - /media/secondary/ganymede/logs:/logs
      - /media/secondary/ganymede/data:/data
      # Uncomment below to persist temp files
      #- ./tmp:/tmp
    ports:
      - 4801:4000
  ganymede-frontend:
    container_name: ganymede-frontend
    image: ghcr.io/zibbp/ganymede-frontend:latest
    restart: unless-stopped
    environment:
      - API_URL=http://192.168.178.55:4801 # Points to the API service
      - CDN_URL=http://192.168.178.55:4802 # Points to the CDN service
      - SHOW_SSO_LOGIN_BUTTON=false # show/hide SSO login button on login page
      - FORCE_SSO_AUTH=false # force SSO auth for all users (bypasses login page and redirects to SSO)
      - REQUIRE_LOGIN=false # require login to view videos
    ports:
      - 4800:3000
  ganymede-temporal:
    image: temporalio/auto-setup:1
    container_name: ganymede-temporal
    depends_on:
      - ganymede-db
    environment:
      - DB=postgresql # this tells temporal to use postgres (not the db name)
      - DB_PORT=5432
      - POSTGRES_USER=ganymede
      - POSTGRES_PWD=ganymede
      - POSTGRES_SEEDS=ganymede-db # name of the db service
    ports:
      - 7233:7233
  # -- Uncomment below to enable temporal web ui --
  # ganymede-temporal-ui:
  #   image: temporalio/ui:latest
  #   container_name: ganymede-temporal-ui
  #   depends_on:
  #     - ganymede-temporal
  #   environment:
  #     - TEMPORAL_ADDRESS=ganymede-temporal:7233
  #   ports:
  #     - 8233:8080
  ganymede-db:
    container_name: ganymede-db
    image: postgres:14
    volumes:
      - /media/secondary/ganymede/db:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=ganymede
      - POSTGRES_PASSWORD=ganymede
      - POSTGRES_DB=ganymede-prd
    ports:
      - 4803:5432
  ganymede-nginx:
    container_name: ganymede-nginx
    image: nginx
    volumes:
      - /media/secondary/ganymede/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - /media/secondary/ganymede/vods:/mnt/vods
    ports:
      - 4802:8080

I have also tried using my servers hostname instead of the IP address in my configuration with the same result. I can provide the logs or any additional info if necessary.

(Looking at similar issues submitted in the past I've gathered that setting the COOKIE_DOMAIN env variable might resolve this. Am I correct in thinking that this is not an option for me, since I do not have a DNS server set up to assign a domain name to my server in my local network?)

Any help would be greatly appreciated. Thank you!

[Zibbp]

Everything looks right. The FRONTEND_HOST environment variable is what sets the allowed CORS origin, required for cookies. To confirm, you're accessing the frontend via http://192.168.178.55:4800? Can you try an incognito window to rule out any extensions?
If you open the browser tools and look at a network request when logging in (should be /api/v1/auth/login), do you see a response header of Access-Control-Allow-Origin? If so, what is the value of it?

In a frontend update in the near future, I'm planning on overhauling how authentication happens. Sending cookies from the server is the best way but is very annoying (see all the issues about this) from a selfhosting perspective as you need to deal with having correct variables in the backend.

[a-dahm]

To confirm, you're accessing the frontend via http://192.168.178.55:4800?

I was, yes.

Can you try an incognito window to rule out any extensions?

Trying to log in in an Edge incognito session without any extensions installed has the same result.

If you open the browser tools and look at a network request when logging in (should be /api/v1/auth/login), do you see a response header of Access-Control-Allow-Origin? If so, what is the value of it?

Upon attempting to log in I see two requests:

Both of these attempt to query http://192.168.178.55:4801/api/v1/auth/login.
The OPTIONS request receives a response with status code 204 No Content and the following response headers:

The POST request does not receive any response and thus has no response headers.

---

I have tested a bit more and after restarting the server completely it (somewhat) works now (although I am not sure how...). If I use the IP-address-based configuration I posted above, I can now successfully log in when accessing the frontend via http://192.168.178.55:4800. This is enough for me, though I would prefer being able to use my servers hostname if possible (I get the same error as before via http://myserver:8400).
If I swap out the IP address for the machines hostname in my configuration however, neither http://myserver:8400 or http://192.168.178.55:4800 allows me to log in.

Like I said, it's not ideal but definitely workable, especially if a future update may resolve this entirely anyway.
Feel free to close the issue unless you would like to get to the bottom of this. Thank you for your time!

[Zibbp]

Odd that is breaks when trying to use the hostname. When you changed the FRONTEND_HOST env var, did you bring the containers completely down docker compose down and back up? Docker requires a complete recreation of the container to change env vars.

[a-dahm]

Yes, I ran docker compose up -d every time I changed the configuration and verified that FRONTEND_HOST etc. changed in Portainer afterwards. Odd indeed.

[HStep20]

Just dropping in to mention Ive been having similar issues. Same troubleshooting steps, checking across browsers without extension, different machines, etc. I tried wrapping the address in quotes, in case the extra colon was throwing things off, as well as trying from different PCs - Nothing worked, same CORS issue when trying to log in.

This is on the latest version: 3.0.1 - but its been happening for months and I finally sat down to fix and update it

[Zibbp]

Just dropping in to mention Ive been having similar issues. Same troubleshooting steps, checking across browsers without extension, different machines, etc. I tried wrapping the address in quotes, in case the extra colon was throwing things off, as well as trying from different PCs - Nothing worked, same CORS issue when trying to log in.

This is on the latest version: 3.0.1 - but its been happening for months and I finally sat down to fix and update it

Can you post your full docker-compose file, redacting any sensitive variables?

[HStep20]

Heres the full compose:

version: "3.3"
services:
  ganymede-api:
    container_name: ganymede-api
    image: ghcr.io/zibbp/ganymede:latest
    restart: unless-stopped
    depends_on:
      - ganymede-db
    environment:
      - DEBUG=false # set to true for debug logs 
      - VIDEOS_DIR=/data/videos
      - TEMP_DIR=/data/temp
      - LOGS_DIR=/data/logs
      - CONFIG_DIR=/data/config
      - TZ=America/Denver # Set to your timezone
      - DB_HOST=ganymede-db
      - DB_PORT=5432
      - DB_USER=ganymede
      - DB_PASS=
      - DB_NAME=ganymede-prd
      - DB_SSL=disable
      - JWT_SECRET=
      - JWT_REFRESH_SECRET=
      - TWITCH_CLIENT_ID=
      - TWITCH_CLIENT_SECRET=
      - FRONTEND_HOST='http://10.0.0.101:4801'
      # OPTIONAL
      # - OAUTH_PROVIDER_URL=
      # - OAUTH_CLIENT_ID=
      # - OAUTH_CLIENT_SECRET=
      # - OAUTH_REDIRECT_URL=http://IP:PORT/api/v1/auth/oauth/callback # Points to the API service
      # WORKER
      - MAX_CHAT_DOWNLOAD_EXECUTIONS=5
      - MAX_CHAT_RENDER_EXECUTIONS=3
      - MAX_VIDEO_DOWNLOAD_EXECUTIONS=5
      - MAX_VIDEO_CONVERT_EXECUTIONS=3
    volumes:
      - /mnt/user/Media/Twitch:/data/videos
      - /mnt/user/appdata/compose-ganymede/logs:/data/logs
      - /mnt/user/appdata/compose-ganymede/data:/data/config
      # Uncomment below to persist temp files
      - /mnt/user/tmp/GanymedeDownloads:/data/temp
    ports:
      - 4800:4000
  ganymede-frontend:
    container_name: ganymede-frontend
    image: ghcr.io/zibbp/ganymede-frontend:latest
    restart: unless-stopped
    environment:
      - API_URL=http://10.0.0.101:4800 # Points to the API service
      - CDN_URL=http://10.0.0.101:4802 # Points to the CDN service
      - SHOW_SSO_LOGIN_BUTTON=false # show/hide SSO login button on login page
      - FORCE_SSO_AUTH=false # force SSO auth for all users (bypasses login page and redirects to SSO)
      - REQUIRE_LOGIN=false # require login to view videos
    ports:
      - 4801:3000
  ganymede-db:
    container_name: ganymede-db
    image: postgres:14
    volumes:
      - /mnt/user/appdata/compose-ganymede/ganymede-db:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=
      - POSTGRES_USER=ganymede
      - POSTGRES_DB=ganymede-prd
    ports:
      - 4803:5432
  ganymede-nginx:
    container_name: ganymede-nginx
    image: nginx
    volumes:
      - /mnt/user/appdata/compose-ganymede/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - /mnt/user/Media/Twitch:/data/videos
    ports:
      - 4802:8080
  ganymede-river-ui:
    image: ghcr.io/riverqueue/riverui:0.3
    environment:
      - DATABASE_URL=postgres://ganymede:PGPWD@ganymede-db:5432/ganymede-prd # update with env settings from the ganymede-db container
    ports:
     - 8233:8080

[Zibbp]

Heres the full compose:

I copied it to a test server and replaced the 10.0.0.101 IP with the IP of my server, I also removed the single quotes in the FRONTEND_HOST env var. I was able to log in fine with Chrome. 10.0.0.101 in the LAN address of your server? If you run the following do you see "Ganymede API" in the output?

docker exec ganymede-frontend wget -q -S -O - http://10.0.0.101:4800

Is the computer you're logging in with on the same subnet?

EDIT: can you also upload a .har from your browser when you attempt to log in? You may need to search how to export it.

[HStep20]

Yep. Thats the Lan address of my server. When running that command, I don't see Ganymede API in the output. This is the full output of the command:

  HTTP/1.1 200 OK
  Content-Type: text/plain; charset=UTF-8
  Vary: Origin
  Date: Fri, 30 Aug 2024 23:19:54 GMT
  Content-Length: 12
  Connection: close

And yep, all computers are on the same subnet. Github doesnt allow .har files as attachments, so I put the text (minus some cookies I took out) into a pastebin for you: https://pastebin.com/g0WcyQTD

I did only test edge/firefox/safari, since I dont use Chrome at all. This is also persistent across all pages. I have the 'require login to see videos' env set to False, but going to the Playlists/Channels page result in a CORS error as well

[Zibbp]

The output of the wget messes up the terminal a bit so I'm assuming that it actually is working because of the 200 response. You could try curl as well:

docker exec -u root ganymede-frontend apk add curl && curl 10.0.0.101:4800 -vvv

You should see "Ganymede API" at the bottom, maybe on the same line as your next shell prompt

zibbp@media:~$ docker exec -u root ganymede-frontend apk add curl && curl 10.0.10.50:4800 -vvv
OK: 16 MiB in 26 packages
*   Trying 10.0.10.50:4800...
* Connected to 10.0.10.50 (10.0.10.50) port 4800
> GET / HTTP/1.1
> Host: 10.0.10.50:4800
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=UTF-8
< Vary: Origin
< Date: Sun, 01 Sep 2024 15:23:20 GMT
< Content-Length: 12
<
* Connection #0 to host 10.0.10.50 left intact
Ganymede APIzibbp@media:~$

If you try removing the single quotes from the FRONTEND_HOST env var, still CORS issues?

I can't actually see the CORS error in the HAR you uploaded. Can you take a screenshot of the error in the console or network tab?

[HStep20]

Interestingly, I went to go test it, and it logged in fine this morning (minus a bunch of bad thumbnails and messed up display layout issues). Ive noticed this in the past when I was having the login issue months ago - It would do the CORS problem, then I would compose-down > compose-up it, and it would let me log in. Lately though, that trick hasnt been working, which is why I added on to the thread. Usually when its a Cors issue, there is no Video section on the main page, but today there was.

When I opened the page, instead of CORS issues, I had 30+ "Invalid Token" errors pop up with a ton of 401s instead.

Seems related to this issue: #490

Unfortunately Im going out of the country for 3 weeks in about an hour, so I won't be able to provide any more info on this until I get back, when it will hopefully return to being a CORS issue.