Open sglebs opened 11 months ago
List of problematic assets I see:
Same problem here
List of problematic assets I see:
- /statics/css/tabler.min.css. This request has been blocked; the content must be served over HTTPS.
- /statics/css/fontawesome.min.css. This request has been blocked; the content must be served over HTTPS.
- /statics/js/vendor/jquery.min.js. This request has been blocked; the content must be served over HTTPS.
- /statics/js/vendor/js.cookie.min.js. This request has been blocked; the content must be served over HTTPS.
- /statics/js/vendor/tabler.min.js. This request has been blocked; the content must be served over HTTPS.
- /favicon.ico. This request has been blocked; the content must be served over HTTPS.
Well, the URL is built with the standard way of building URLs for each file you mentioned: the url_for
method.
I had that problem once when I tried to access the server without a domain, using the IP address of the server. You might be having the same problem.
Using protocol-less URLs would be a simple fix. Not sure if Jinja2 supports this easily though.
I think it is not about Jinja2, since it's only a template engine...
Temporary solution I found is using the Content-Security-Policy: upgrade-insecure-requests
header.
add_header 'Content-Security-Policy' 'upgrade-insecure-requests';
(in NGINX, for example)
This solved the issue for me on GCP (Cloud Run)
--forwarded-allow-ips="*"
In dockerfile:
CMD ["gunicorn", "-w", "3", "-k", "uvicorn.workers.UvicornWorker", "src.main:app", "--timeout", "0", "--forwarded-allow-ips", "*"]
Is your feature request related to a problem? Please describe. Under many cloud platforms it is common to get page rendering without CSS. You will see that the browser blocks the mixed protocol use (https versus http).
Describe the solution you'd like
A URL can be in the form of "//host:port..." instead of "http://host:port..." or "https://host:port...". Using the protocol-less URL allows the URL to be adaptive and use http or https just like the current page. If starlet-admin used URLs in this format, a lot of pain would be avoided. See #280
Describe alternatives you've considered
For fly.io I have had to use:
Now I am going through the same pain in Azure.
Additional context
Using protocol-less URLs would be a simple fix. Not sure if Jinja2 supports this easily though.