Form URL not using HTTPS although base URL contains the prefix ("Insecure form submission")

[TheAssassin]

I'm currently evaluating CiviCRM standalone installed via Docker. Whatever I do, I run into the following problem.

The "domain" form (see screenshot) does not use HTTPS. The "base URL" specified during the installation contains the https:// prefix, though, I also verified this in the config files.

What could be the reason for this behavior?

Please note that I use Traefik as a reverse proxy. All proxy headers are forwarded correctly:

Upgrade-Insecure-Requests: 1
X-Forwarded-For: 172.29.1.1
X-Forwarded-Host: XXXX.YYYY.ZZ
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Server: <random hash>
X-Real-Ip: 172.29.1.1

I can convince the browser to submit the form by changing the URL manually and this specific form hardly needs to be submitted, but it's very annoying and not usable for less tech-savvy people. I'd appreciate any pointers.

[TheAssassin]

Side note: this might not be an issue with the Docker image; if so, please transfer where applicable. Looking at the code, it should respect the X-Forwarded-Proto header, though.

[TheAssassin]

Update: the issue also affects plenty other forms, e.g., the report pages. I have not found a workaround yet.

[TheAssassin]

Enabling "Force SSL" causes an endless redirect loop and shows the following log messages:

2025-01-06 02:27:26+0000  [warning] CiviCRM thinks site is not SSL, redirecting to {url}
Array
(
    [url] => https://civicrm.***/civicrm/admin/setting/url?reset=1
)

Edit: possibly related: https://civicrm.stackexchange.com/questions/46054/civicrm-thinks-site-is-not-ssl-redirecting-to-url

[TheAssassin]

Apparently, this is related to the reverse proxy setup, i.e., the apache2 config. When setting $_SERVER['HTTPS'] = 'on'; in the CiviCRM config, it suddenly works as expected. PHP must be thinking it's not running behind a TLS-terminating proxy, and the reverse proxy setup does not provide an HTTPS ingress (with a self-signed certificate, for instance).

I see two options out of here that can be implemented in this repository:

• Provide an HTTPS endpoint (with a self-signed cert) and use that from the reverse proxy (w/o validating the TLS certificate)
• Make the reverse proxy read and understand X-Forwarded-Proto

I'm not really into PHP, so I can't tell what would cause $_SERVER['HTTPS'] to be "on", but I think it'd be the cleaner solution. Using TLS between the proxy and CiviCRM is an acceptable trade-off, though.

Another option would be for CiviCRM to fix its static URLs by just using the absolute URL provided by the user in the installer. I mean, this is kind of a security-relevant design issue.

[michaelmcandrew]

Hey @TheAssassin - sorry to take a while to reply.

I think the answer if likely that we should do something similar to michaelmcandrew/civicrm-docker@5658788.

Let me know what you think.