Important upgrade notice

Soon version 7.3 of the WordPress + Office 365 (login) plugin will be released and contains two important updates that possibly affect existing users.

Bypassing server side caching (your login might be tampered with)

TL;DR A new setting Don’t try to bypass (server side) cache has been added and it is not checked by default. This means that by default the plugin will now always add an extra redirect before sending the user to Microsoft‘s Identity Provider to prevent caching plugins and solutions from replaying an old request with a stale NONCE value, resulting in the dreaded “Your login might be tampered with.” error message. If you have not been affected so far by this issue, you can go to the Miscellaneous tab in the wizard and check the box and by doing so manually disable the plugin tying to bypass server side caching. This solution has been successfully tested on various “known” hosters e.g. dreamhost.com and wpengine.com.

The long story The issue at hand is caused by so-called server side caching that you yourself added to your website (through plugins such as WP Rocket, W3 Total Cache or WP Super Cache) or your hoster added. Important is to understand that this issue isn’t caused by your browser but instead the server “remembering” the output produced by a PHP script / page. Instead of processing the page, the cache basically short-circuits the page’s processing and sends the output as it remembered it from the very first time (at least since the cache was purged) the page was processed. The output produced by the WordPress + Office 365 plugin, as you probably know by now, would be a redirect to Microsoft’s so-called Identity Provider (where you as user can authenticate yourself) that in turn would send you back to your website. Unfortunately, caching would “remember” the redirect and use the exact redirect URL each time a user would navigate to the page (and didn’t already authenticate successfully prior to navigating to the page). This is very unfortunate, because the redirect URL contains a so-called NONCE (= Number used Once) that is then sent back to the website by Microsoft along with the user’s identitiy information (when the user did authenticate successfully). When the plugin receives this information it would test the NONCE value to make sure that an old request isn’t “hijacked” by someone with bad intentions who would like to break into your website. But – I’m sure you now understand what is coming – the NONCE value is no longer valid (it has become stale by now) and hence the plugin rejects the login attempt.

To work around this, the plugin has now been updated as follows. On the Miscellaneous tab you’ll find a new setting Don’t try to bypass (server side) cache. When checked the plugin will do nothing to prevent cache (if any) from interfering with requests to Microsoft’s Identity Provider. However, if not checked (now the default setting), the plugin will not redirect the user immediately to Microsoft’s Identiy Provider. Instead it will redirect the user to your WordPress Admin e.g. https://www.yourwebsite.com/wp-admin/?redirect_to=https://www.yourwebsite.com/the-page-you-tried-to-load-initially because most caching plugins and solutions only cache WordPress posts and pages but not content under /wp-admin. The plugin will then detect that a user tries to access the /wp-admin admin area and also detects the redirect_to information and will understand that this request should be redirected to Microsoft’s Identity Provider. This way, caching is bypassed.

Support for WordPress multi-sites

TL;DR If your WordPress isn’t a multisite network, you can safely ignore the following information. WordPress multisite networks have been supported since version 3.0 but the implementation never has gotten the attention it deserves. With version 7.3 this has changed and a new global constant WPO_MU_USE_SUBSITE_OPTIONS has been introduced to allow administrators of a WordPress multisite network to toggle between two scenarios:

• Shared All subsites in the network share the same Azure AD application registration
• Dedicated All sites in the network will have to be configured individually.

The dedicated scenario can be configured by adding the following line to your wp-config.php

define( 'WPO_MU_USE_SUBSITE_OPTIONS', true );

If you don’t add this line or add it but set WPO_MU_USE_SUBSITE_OPTIONS to false, the plugin will select the shared scenario.

To configure the plugin and Single Sign-on, as an administrator, you will need to navigate – in case of the shared scenario – to My Sites > Network Admin > Plugins > WPO365 Login > Configuration. On the other hand – in case of the dedicated scenario, administrators need to navigate to each individual site’s Admin Dashboard > Plugins > WPO365 Login > Configuration.

Thanks for your business and more importantly, thanks for your trust!

Marco van Wieren
WPO365 – Connecting WordPress and Office 365
Zurich, Switzerland