I’m trying to deploy Kirby to my production environment. The production environment only supports HTTPS requests (also tried this out with redirecting HTTP to HTTPS). On my Kirby login page I get a lot of errors in my console because the login page requests files in the head that all have a HTTP url leading to Mixed Content errors. I don’t know how I can address this problem and this code probably stems from the index.html of Kirby’s Vue implementation. Currently my login doesn’t work because of this. It seems like bad practice to me to unnecessarily request assets via HTTP instead of HTTPS without any necessary reason.
How do I solve this problem?
All the Best
Using Kirby 3.7.1
Set my URL in Kirby config explicitly to an https address
All assets that are intended to be loaded via HTTP from login page are either not accessible this way or requests are being redirected to HTTPS
It’s Apache with PHP8.0 running within an EC2 instance. It’s within the HTML source code that I see in the Chrome devtools so I guess it’s coming from Kirby. Basically an HTML with a head and a body with a single div with the default id that is used as a render target for Vue.
AWS Cloudfront is redirecting all HTTP requests to HTTPS requests.
But I don’t think this is relevant here, because the Login is on a HTTPS page and these HTTP requests get blocked from the Browser and aren’t reaching the server.
The origin of these http:// urls are on Kirby’s login page or am I getting something wrong here?
But the question is rather, how these http urls get there. As I said before, Kirby doesn’t hard-code any http requests anywhere. There are enough sites out there that work perfectly fine, so the task here is to find the problem in the setup, so yes, this is relevant.
This always happens when the Kirby instance itself is running under http, and the https requests from outside are terminated elsewhere, but the Kirby instance itself doesn’t know about it. In those cases, unfortunately, the absolute URLs are rendered with the wrong scheme http.
For example, this is a problem when running Kirby in Docker containers with nginx. There, nginx runs on default http with port 8080, and the https traffic is terminated via an upstream traefik container, for example. I have also opened tickets and posted articles here in the forum about this.
And the problem is really annoying. It would be so easy if you could tell Kirby with a parameter “hey, kirby, you’re running in https context, so render everything in https”.
But it’s not that simple.
There is a URL parameter in Kirkby’s config for this. That also worked quite logically until a few versions ago. But now it works differently. You have to enter a URL with schema there. For sites with multiple URLs this is difficult again (e.g. with and without “www”).
The only way I know is to create a config.<domain>.php file for each domain, which always contains the url parameter with the whole domain URL and https as schema. I wish this was solved nicer (see Laravel example, there is an AppServiceProvider configuration and there you can say that the whole instance runs in HTTPS mode). Another solution is to set the correct X-Proxy headers, but this again requires customizing the nginx configuration, which in the Docker environment, for example, means creating custom images or bind-mounting custom config files at runtime, which unnecessarily complicates configuration and maintainability. It would be super awesome if the Kirby team would revisit this issue at some point. I would be happy to offer my help.
I would agree that it should be possible to set the scheme://hostname:port in a backend application if one would like to do so.
However, I think it would be still better to let the application unaware of this, because otherwise, you could not serve the application via 2 or more different URLs on 2 or more different proxies.
Thus, to be flexible enough, it is better to forward the requested hostname from the proxy to the backend (ProxyPreserveHost in apache and proxy_set_header Host $host; in nginx). Of course, the more flexibility, the more complexity.
