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.