I am trying to establish a CMS site that uses completely HTTPS protocol, which is working, but when I try and access the commerce site via the manager integration, I am getting a lot of mixed content errors which is causing the site to not load properly.Mixed Content: The page at 'https://www.domain.com/commerce/Apps/Shell/Pages/default.aspx' was loaded over HTTPS, but requested an insecure stylesheet 'http://www.domain.com:8011/Commerce/Apps/Shell/styles/ComboBoxStyle.css?v=18.104.22.1687'. This request has been blocked; the content must be served over HTTPS.I looked at the baf.security.config file and have updated that to use SSL, but that doesn't seem to make any bit of difference. Why would the resources being requested by commerce be sent over an HTTP connection instead of an HTTPS connection?
I ended up adding a Content-Security-Policy: upgrade-insecure-requests response header which forced the content to be loaded via https, which seems to have done the trick. Ideally, it would be great if Epi were to use the url from the web config from the cms, or else have a setting that allows you to change all the links to be https instead of http (perhaps I am missing that setting).
I've had a similar problem, but its actually on the Promotions section of Commerce Manager. Whenever you use any fields to add SKU/Products that causes an ajax callback, it fails. Initially it is the issue you mentioned above where I've added the HttpProtocol CustomHeader.... but then when that is in place you get a 302 redirect to the login page which fails ultimately.
I don't suppose you came across this did you later? As i've been a bit stumped on this one now, tried all kinds of re-write rules.
Unfortunately, I am not using Promotions in my code, so I haven't come across this issue.
Ah ok - i'll keep on looking. Thanks for the quick response
Commerce Manager does not work over HTTPS if the encryption is terminated at the load-balancer.
The views use CommerceHelper.GetAbsolutePath(string)
This little ****** uses the HttpContext.Current.Request.Url as a base for the absolute URL.
So, if the request is decrypted on the load-balancer, then the Site receives request using HTTP scheme, and thus will create absolute URL using HTTP.
We are working on this issue, it will be fixed in upcoming releases.
We have a fix for this in the upcoming release 10.6.0. If you want to test for the fix, contact us directly and we can send you a pre-release build.
Thanks & regards,
Commerce 10.6.0 was released yetserday.
Steven Carter: In which file did you add the Content-Security-Policy: upgrade-insecure-requests response header?