felddy/foundryvtt-docker

Auth Page not loading correctly

k4rm4c0m4 opened this issue · 8 comments

k4rm4c0m4 commented

Bug description

In case it matters, the whole thing runs behind a reverse proxy, more specifically caddy & is also behind cloudflares proxy servers. Since I am able to access the page and was able to set it up completely once before restarting, I do not think the issue stems from there. I have disabled caching & proxy completely for testing and have not found a noticable improvement.

When (re)starting the container, it redirects to /auth and fails to load the screen entirely and produces two errors in the log.

foundry.js:4194 Uncaught SyntaxError: Unexpected identifier '#type' (at foundry.js:4194:69)
setup.js:7 Uncaught ReferenceError: Application is not defined
    at setup.js:7:22
    at setup.js:5696:3

From here, you cannot use the application correctly.

For reference, my Docker-Compose is as follows:

---
version: "3.8"

services:
  foundry:
    image: felddy/foundryvtt:release
    hostname: https://foundry.domain.tld
    volumes:
      - type: bind
        source: ./data
        target: /data
    environment:
      - PUID=1002
      - PGID=1003
      - TIMEZONE=Europe/Berlin
      - FOUNDRY_PASSWORD=
      - FOUNDRY_USERNAME=
      - FOUNDRY_ADMIN_KEY=karmasecret
      - CONTAINER_VERBOSE=true
    ports:
      - target: 30000
        published: 30000
        protocol: tcp
    restart: unless-stopped

Logs do not show anything suspicious. License authentication is reported as working, nothing out of the ordinary.

Steps to reproduce

  • Create a container using a barebones docker-compose, as provided in the docker-compose.yml example in this repository.
  • Set up the Server
  • Reboot the System (or the container)

Expected behavior

Make the authentication page load correctly to allow the user to access the UI.

Container metadata

com.foundryvtt.version = "11.311"
org.opencontainers.image.authors = "markf+github@geekpad.com"
org.opencontainers.image.created = "2023-09-29T00:03:59.458Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "2fac62dd530713a68bdb4f9650b94600abdb50e3"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "11.311.0"

Relevant log output

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
felddy commented

This sounds like a web socket issue with your reverse proxy.

See:

k4rm4c0m4 commented

Will investigate, though I have configured my reverse proxy to use websockets and a similar configuration works on most of my other services without problem. Thanks for the direction!

gaschenk commented

I can confirm this issue on any chromium based browser, whereas this issue as well as some following websocket issues are explicit to chromium based browsers.
Everything else does work completely fine in Firefox.

Additionally mobile versions of Edge, Chrome etc. work fine as well so it seems to be an issue with Chromium based browsers and Websockets on Desktop.

felddy commented

Adding a link to your thread about this issue on Discord:

I wish I could provide some assistance, but I can't think of a way this could be related to the tooling of this container. This does seem like a nuanced proxy configuration issue to me. You're welcome to continue to investigate the cause here, but I don't think I'll have much to offer. I'll keep an eye on the conversation in case anything actionable comes up.

pbasov commented

My setup is Caddy VPS with Cloudflare TLS -> Wireguard -> Docker machine

The issue for me was enabled proxy in Cloudflare, the problem seemingly went away as soon as I disabled it.
Will keep monitoring, by so far so good.

  • 👍1
gaschenk commented

My setup is Caddy VPS with Cloudflare TLS -> Wireguard -> Docker machine

The issue for me was enabled proxy in Cloudflare, the problem seemingly went away as soon as I disabled it. Will keep monitoring, by so far so good.

I can generally confirm this but it seems to be an issue between Cloudflare & Chromium browsers that makes the proxied websocket tunneling prematurely behave flaky or rather prematurely kill the connection from the client.

github-actions commented

This issue has been automatically marked as stale because it has been inactive for 28 days. To reactivate the issue, simply post a comment with the requested information to help us diagnose this issue. If this issue remains inactive for another 7 days, it will be automatically closed.

github-actions commented

This issue has been automatically closed due to inactivity. If you are still experiencing problems, please open a new issue.