What I recall hearing from others (Iām far outside of my comfort zone here) is that youāll need to use AJP both as proxy and reverse proxy in your virtualhost, as well as make sure that all related services are communicating over SSL, not just the web frontend.
I get this error message in my Chrome console, when I click āSaveā on e.g. a new portlet.
Mixed Content: The page at āhttps:/mypage.no/admin/adminpage?page=0ā was loaded over HTTPS, but requested an insecure form action āhttp://mypage.no/admin/adminpage?op=browse&menukey=0&page=900ā. This request has been blocked; the content must be served over HTTPS.
I enterpret it as the page trying to do a POST to a http-resource, and the browser denying it.
Iāve set up the ssl in my apache reverse proxy. But it doesnāt rewrite urls, in the content. (the url of the formsubmit in admin. Should it?
Did this happen when you were saving content? Or changes to a portlet? Was the changes saved, so you could later find it?
The http-URL from the error message is actually a GET request, fetching the portlet list in site 0. My guess is that you are saving a portlet, then being redirected to the full list of portlets after the save has completed, only that the URL used for the list incorrectly uses normal http. If this error keep happening, please submit a support ticket at: http://support.enonic.com/
@jsi It happend both when I was saving content, and a portlet. And yes, it appears that my portlet actually was saved. And I think you are correct when it comes to the redirect.
At the moment we are looking into exposing the admin part of the site on port 80.
But Iām surprised that this isnāt something that has come up in every Enonic 4.7 project ever.
If someone has a working installation of Enonic 4.x exposing the admin site on 443 (https), please come forward and tell me what the trick is! Please!
Hereās an example apache virtualhost config from a site that was exposing admin on port 80 with SSL and running Enonic CMS 4.7 using Tomcat. Disclaimer: Iām way out of my depth, so I canāt help you with answers regarding any specifics below. But hopefully this can be useful?
I know we do not have a lot of customers running our admin console on https, but there are a few. For a while, we had problems making our Ajax-calls work with https, but this was not a big problem, because Ajax is used very sparingly, mostly for status updates and progress bars, so basically everything worked, with just reduced feed-back. This should now be solved. I have never seen or heard of a problem like yours, but I do not work in operations.
If BjĆørnars configuration is not helpful, I will try to involve some of our operations people in this thread.