Secure admin access

Admin system access used to use a certificate secured https URL to secure the admin login screen. Thereafter the rest of the admin system worked over either protocol. Historically on older browsers this was simpler and prevented issues with rendering wysiwiyg elements under https.

Browsers and acceptable levels of security and encryption have changed. 11.0 defaults and forces the CMS administration system to be secure from end to end. This means that all editorial access to the administration are encrypted.

There is a down side to this. Depending how a site has been built some users will see mixed content warnings whilst administering their sites. This is caused by mixed secure content on the site and produces messages like “This site has insecure content;” “only secure content is displayed;” “Firefox has blocked content that isn’t secure.” etc. This can also produce pop-up warnings on some browsers such as shown below.

What causes this is the fact that some of the older web pages were created with absolute references to some resources. So for example within the page an image may have been called via a reference like "http://www.yourURL.net/pictures/headerImages.jpg", when it should have been called using a relative reference like "/pictures/headerImages.jpg". Because the editor in the CMS tries to render the content of the page you are trying to edit such references will cause a mixed content warning.

As well as presenting different types of warnings in reaction to mixed content browsers also behave differently. IE now blocks all scripts from executing if there is non-https content present, it will also block cookies. These will seriously affect you ability to edit these pages until the mixed content has been removed

Dealing with Mixed content warnings

In terms of what you can do about this, you have three options:

• In the first case you can ignore it. The warning is not serious so if you're the sole editor of the site and are OK with the explanations then it's fine, that said the disabled script and cookies described above will affect the admin system adversly.
• The second, preferred, option is that you go through your site and edit out the absolute URL references. There shouldn't be that many and they're regarded as bad practice anyway. The best approach for doing this is to load the offending page into a browser looking at the source and searching for "http:", alternatively many of the developer toolbars (F12) in modern browsers will highlight these kinds of things.
• The third option, for deployed clients only, is to turn off the https aspect of the admin system via an IIS setting, we wouldn't recommend that.