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

[kevinsnijder]

I have the same problem, currently unable to make an NGINX reverse proxy to the pelican panel.
Edit: Fixed it with the caddyfile @Morpheus636 provided

[redthirten]

I just wanted to confirm this issue as well. Was trying to place the panel behind a Traefik reverse proxy that provides and terminates TLS for multiple sites, but ran into a slew of confusing issues:

• I first naively set SKIP_CADDY: true thinking the container's internal Caddy instance was only providing a reverse proxy service. I had no idea it was also providing the webserver for php-fpm until I Googled php-fpm and learned it wasn't the webserver itself.
• I then saw a support post in the Discord suggesting I try setting APP_URL to "https://mydomain.com, http://, https://". This got the panel working and connectable, but broke the SMTP Mail Driver because it was setting the HELO/EHLO argument to "mydomain.com, http", which my mail server denied.
• I tried playing around with the TRUSTED_PROXIES environment variable, but I think it's broken? The panel expects this value to be an array, so setting it simply to "127.0.0.1" gives a 500 error on the admin settings page for providing a string when an array is expected. I'm not sure how to specify an array in my docker-compose file that would translate to a php-accepted array value.
• Finally, I found this Issue thread which solved all my confusion (thank you @Morpheus636 !!!). I implemented Option 1, it worked like a charm, and I find it to be the path of least resistance in hindsight. My Traefik reverse proxy automatically forwards all HTTP traffic to HTTPS, so hopefully the previously mentioned security implications are thwarted by that, but please educate me if it doesn't.

[Lovinoes]

I just wanted to confirm this issue as well. Was trying to place the panel behind a Traefik reverse proxy that provides and terminates TLS for multiple sites, but ran into a slew of confusing issues:

* I first naively set `SKIP_CADDY: true` thinking the container's internal Caddy instance was only providing a reverse proxy service. I had no idea it was also providing the webserver for php-fpm until I Googled php-fpm and learned it wasn't the webserver itself.

* I then saw a support post in the Discord suggesting I try setting `APP_URL` to "https://mydomain.com, http://, https://". This got the panel working and connectable, but broke the SMTP Mail Driver because it was setting the HELO/EHLO argument to "mydomain.com, http", which my mail server denied.

* I tried playing around with the `TRUSTED_PROXIES` environment variable, but I think it's broken? The panel expects this value to be an array, so setting it simply to "127.0.0.1" gives a 500 error on the admin settings page for providing a string when an array is expected. I'm not sure how to specify an array in my docker-compose file that would translate to a php-accepted array value.

* Finally, I found this Issue thread which solved all my confusion (thank you [@Morpheus636](https://github.com/Morpheus636) !!!). I implemented Option 1, it worked like a charm, and I find it to be the path of least resistance in hindsight. My Traefik reverse proxy automatically forwards all HTTP traffic to HTTPS, so hopefully the previously mentioned security implications are thwarted by that, but please educate me if it doesn't.

I want to confirm this issue as well. I experienced the same problems while using NGINX as a reverse proxy instead of Traefik. It only works when setting the APP_URL to HTTP instead of HTTPS, which seems counterintuitive. The same problems with SKIP_CADDY, TRUSTED_PROXIES, and SMTP also occurred in my setup