Form Not Secure Messages - then unrecoverable crash after adding FORCE_HTTPS=true

[richard7ac]

When using studio I noticed the message "The form is not secure. Autofill has been turned off."
Upon checking I notice that all of the internal links are absolute http://xxxxxx

I tried updating the FORCE_HTTPS to true as I use a Traefik proxy in front but this resulted in errors, just in case I changed my proxy to connect to littlelink using https also in case of "internal confusion" this did not resolve and I noticed bad gateway messages.

Checking my docker container logs I then noticed

Running Apache
AH00526: Syntax error on line 337 of /etc/apache2/httpd.conf:
Invalid command 'io', perhaps misspelled or defined by a module not included in the server configuration
Updating Configuration: Apache Base (/etc/apache2/httpd.conf)
Updating Configuration: Apache SSL  (/etc/apache2/conf.d/ssl.conf)
Updating Configuration: PHP         (/etc/php8/php.ini)
Updating Configuration: Complete
Running Apache
AH00526: Syntax error on line 339 of /etc/apache2/httpd.conf:
Invalid command 'io', perhaps misspelled or defined by a module not included in the server configuration
Updating Configuration: Apache Base (/etc/apache2/httpd.conf)
Updating Configuration: Apache SSL  (/etc/apache2/conf.d/ssl.conf)
Updating Configuration: PHP         (/etc/php8/php.ini)
Updating Configuration: Complete
Running Apache
AH00526: Syntax error on line 341 of /etc/apache2/httpd.conf:
Invalid command 'io', perhaps misspelled or defined by a module not included in the server configuration
Updating Configuration: Apache Base (/etc/apache2/httpd.conf)
Updating Configuration: Apache SSL  (/etc/apache2/conf.d/ssl.conf)
Updating Configuration: PHP         (/etc/php8/php.ini)
Updating Configuration: Complete

I had to revert the configuration change manually which I did by editing the .env file and changing FORCE_HTTPS=false
This had no effect so I stopped and restarted my docker instance and it kept repeating the above - the instance was basically restarting due to the apache error.

So two related (I hope issues).

1. Internal links are absolute when then could be relative, but if absolute should be https (is this what FORCE_HTTPS does)
2. When adding FORCE_HTTPS=true this had a negative effect which was unrecoverable

In the end I recreated the docker instance and used new persistent volume and reconfigured from scratch and now I am back to the insecure http links.

[JulianPrieber]

Hey Richard,

Force https simply redirects any internal route to HTTPS.

This setting was implemented for our Apache users, who normally can just put their instances in their web root, and it works just like that. Previously, redirection to HTTPS was the default behavior of the application. With the release of the Docker Edition, we wanted to support HTTP, so we made this feature optional and turned it off by default.

If you were to turn this option on when accessing your page through a reverse proxy over port 80 the request would still be redirected to HTTPS. Even tough your proxy supports SSL, if the request is done over port 80 the request will still be redirected to HTTPS. This causes a mismatch error on the proxy side and your setup will break.

I tried mentioning this in the config description, but I think it didn't really get the point across.

In the new version of the config, everything is done with a GUI, mostly with toggle switches. I added a description that hopefully communicates the danger of this setting more clearly.

All links will be either HTTP or HTTPS depending on if you access them over HTTP or HTTPS... Even if it's accessed through a reverse proxy, if it's setup to access the page over HTTP the links will be as such.

This is why our documentation for a reverse proxy for the docker instance recommends either setting up the proxy pass with HTTPS or adding headers that redirect links to HTTPS.

In short: This setting was simply implemented because some Apache users complained about their instance not being HTTPS by default anymore, like it was before.

I hope this helps to clarify some things 👍

[richard7ac]

Julian - I thought I had already replied to this - but cannot find it so I hope I am not duplicating this!!
Firstly - thanks for the explanation, I am still trying to fight with traefik to get it to connect to https on the backend with self signed certificates however - 2 things if I may.

1. Why not just switch to using relative links within the HTML so instead of http(s)://littlelink.example.com as the prefix just make it / so a link for http(s)://littlelink.example/img/image1.png becomes /img/image1.png - you might even not need the first character forward slash - the browser would convert it for you
2. Other option would be to take a look for any X-FORWARD header - I created a small php program within the container to check what was being sent by traefik by default as it does a lot of the lifting that NGINX would need to be configured for see below, as you can see the HTTP_X_FORWARDED_PROTO has https in it - when not going via the Proxy this is not available - this is found in the $_SERVER variable of PHP. X-FORWARD headers are fairly standard method used with Load Balancers.

HTTP_X_FORWARDED_FOR: 10.10.1.4      (client IP address)
HTTP_X_FORWARDED_HOST: littlelink.example.com    (host name of the server being connected to)
HTTP_X_FORWARDED_PORT: 443      (original port number)
HTTP_X_FORWARDED_PROTO: https    (protocol being forwarded for)
HTTP_X_FORWARDED_SERVER: proxyserver   (host name of the proxy server)
HTTP_X_REAL_IP: 10.10.1.4   (client IP address again)

[richard7ac]

OK - finally got traefik to accept the self signed certificate - not totally happy with the config I have as it's not exactly what traefik documents as the recommended solution - but still think the backend should be able to connect HTTP and used the HTTP_X headers I mention above - but I will leave it with you to ponder!!

[JulianPrieber]

Why not just switch to using relative links within the HTML so instead of http(s)://littlelink.example.com as the prefix just make it / so a link for http(s)://littlelink.example/img/image1.png becomes /img/image1.png - you might even not need the first character forward slash - the browser would convert it for you

My issue is that I'm unsure of how I might accomplish this in a way that would be sensible and comparable to our current system.

I need a way to preserve relative paths. I just adapted the way relative URLs were handled in our predecessor project. Currently, we generate links based on the base URL of the application.

In a subdirectory, this could be https://example.com/llc/. So for the path https://example.com/llc/panel/index
this would still output https://example.com/llc/.

If I just were to stop using this function and simple add links like href="css/app.css" in most pages, this would result in llc/css/app.css which is the correct path. But on some routes the URL might be something like https://example.com/llc/panel/index so here the path would be llc/panel/css/app.css which would be incorrect and result in an error 404.

I could simply resolve this by adding links with href="../css/app.css" which would work in this case. But this would increase the workload and oversight required for each page. Furthermore, this would require these URLs to be changed manually each time a route would be changed.

Due to the reasons stated above, I would require a fairly easy to implement and universally applicable function to do this.

Unfortunately, I am not aware of any built-in Laravel or PHP function that can accomplish exactly this.
I am currently looking for a solution for this. I might be able to make a custom function to do this.

[JulianPrieber]

I could just implement an option to turn any link into HTTPS. This would also work for reverse proxies.
So if you access the page over http all links would still be https.
It's just a single line, and I could turn this into an optional setting.

This might be the most effective and easiest solution to implement.

[JulianPrieber]

I might move this option to the advanced section.

[JulianPrieber]

I will probably include this in the patch on Monday.

If turned on, this option will cause mixed content errors when accessing the page over HTTP, but this won't break anything and the page is still usable.
This does not affect reverse proxies.

[JulianPrieber]

This is the previous option (previously FORCE_HTTPS now FORCE_ROUTE_HTTPS). This is in the advanced section.