Docker image will not serve on HTTP if the site URL is https

[Morpheus636]

Current Behavior

The Caddyfile uses the SITE_URL environment variable to set the route on which Caddy will serve the panel.

If you place the panel behind a reverse proxy that provides and terminates TLS (such as a different Caddy instance used to serve multiple sites), SITE_URL is supposed to start with https://.

With SITE_URL beginning https://, Caddy will redirect any traffic on port 80 (including from the reverse proxy server in front of it) to 443, causing too many redirects.

Expected Behavior

Caddy allow the site to be served on HTTP or HTTPS, regardless of the SITE_URL.

Steps to Reproduce

To reproduce the redirect behavior:

1. Deploy the Docker image with SITE_URL beginning with https://
2. Attempt to access the container over port 80 and notice a 308 redirect to HTTPS.

To reproduce the too many redirects error:

1. Deploy the Docker image with a SITE_URL beginning with https://
2. Point the DNS for the domain in SITE_URL to a different caddy instance, configured to reverse_proxy to port 80 on the panel.
3. Access the second Caddy instance and observe the too many redirects error.

Panel Version

v1.0.0-beta17

Wings Version

N/A

Games and/or Eggs Affected

N/A

Docker Image

N/A

Error Logs

N/A

Is there an existing issue for this?

• I have searched the existing issues before opening this issue.
• I have provided all relevant details, including the specific game and Docker images I am using if this issue is related to running a server.
• I have checked in the Discord server and believe this is a bug with the software, and not a configuration issue with my specific system.

[Morpheus636]

Other notes:

• Setting SITE_URL to http:// prevents the redirects, but causes errors when the site is served on HTTPS by the proxy, because the panel will attempt to access assets via HTTP.
• Setting the second Caddy instance to access the panel via https causes 502 errors.

Possible solutions:

I'm happy to open a pull request for either of the first 2 options, if there's a consensus about which one to implement.

Option 1: HTTP Catch-all

Change the Caddyfile built into the image to include an http:// catch-all rule. This can be done fairly easily, but requires disabling the implicit http->https redirect, as Caddy processes the redirect before the catch-all rule. source

This could have security implications (in that users could access the panel without SSL) but administrators could solve them by not forwarding port 80. That would cause connection refused errors should someone explicitly specify http://, should not affect modern browsers that use HTTPS by default.

Example (this is what I've used in my test deployment):

{
    admin off
    email {$ADMIN_EMAIL}
    auto_https disable_redirects
}

{$APP_URL} http:// {
    root * /var/www/html/public
    encode gzip

    php_fastcgi 127.0.0.1:9000
    file_server
}

Option 2: New Environment Variable

Create a new environment variable, such as SERVE_ON, to use instead of APP_URL only in the Caddyfile. The new variable could default to APP_URL if not specified, to avoid requiring additional configuration for "normal" installs.

Option 3: Document SKIP_CADDY

Document that running the panel behind a proxy that terminates TLS will not work and that users who want to do so should use SKIP_CADDY. Personally, this is my last choice; the other two options are relatively simple to implement, require little to no ongoing work from maintainers, and give the user more flexibility.

[SirEndii]

I've enabled caddy and served container port 80 to host port 9001 with a custom caddy file
I am not an expert on this - this is just how I did it/how someone recommended to me to do it
See #967 if you are interested (Or even maybe you see some issue with that deployment)

[Morpheus636]

I've enabled caddy and served container port 80 to host port 9001 with a custom caddy file

That's the Option 3 I listed (use SKIP_CADDY and host entirely with an external web server). It is a valid workaround, but I would much prefer to keep the panel container self-contained and reverse proxy to its built-in webserver.

[SirEndii]

I agree at this point