So one potential issue I’ve found was that I was using
//cdn-url.example.com
in my app.yml
– changing it to
https://cdn-url.example.com
made things better, there are no errors now.
So one potential issue I’ve found was that I was using
//cdn-url.example.com
in my app.yml
– changing it to
https://cdn-url.example.com
made things better, there are no errors now.
Yes, I had the same problem @itsbhanusharma. It’s too bad our default CSP policy doesn’t allow CDN URLs of the protocol agnostic form
//discourse.cdn.example.com
Is there some reason why we hard-coded this to https instead of being protocol agnostic @sam? Does CSP require https?
Protocol agnostic CDN is a bad practice, we should not be using that anywhere really.
Besides, CSP specification mandates the protocol scheme to start with a letter, which rules out the //
; or to use no protocol at all (just the hostname, or none
, or self
, etc.) – which also works, but indeed the mix of HTTPS and HTTP already causes browsers (at least Firefox) to turn the green lock into a grey lock with an orange warning sign. No very user friendly.
Should we just silently convert a schemeless CDN to https on config file load?
mayyyyybe… I kind of prefer not to cause we will still be lumped with fixing all history with a remap anyway.
I think a rebuild should freak out if it sees a CDN beginning with //
and return a console error advising the user that this is a bad practice, and refuse to progress.