Even when you followed the instructions carefully, you may still struggle getting the plugin to work. In this post we have tried to address the most common issues and what you can do overcome them.
If you have further questions after reading through this section or the plugin is not working according to your expectations, you can acquire additional support.
If you want to better understand why the plugin is not working, it may be a good idea to enable (debug) logging. To do so, you first need to enable logging in WordPress. You can do this by changing the following line in the wp-config file
define( 'WP_DEBUG', false );
define( 'WP_DEBUG', true );
and by adding the following lines:
define( 'WP_DEBUG_DISPLAY', false);
define( 'WP_DEBUG_LOG', true );
Then you can navigate to the WPO365 Options page and the box for enable Debug Mode. You should now find the WordPress debug.log in the wp-content directory. Once everything is working correctly you should turn this logging of because the file quickly grows and nobody wants a server running out of diskspace.
If the plugin silently fail, there is an ever so slight chance that the key NONCE_SALT is missing in your wp-config.php file.
When your WordPress website runs in a hosting environment with enhanced caching capabilities, changes are that your run into all kind of unexpected problems. This may especially be the case, if you configured the plugin to authenticate all requests (see Intranet Scenario). In this case the caching service offered by a caching plugin e.g. WP Rocket or by your hosting provider may intercept page requests and serve static HTML as a response (instead of WordPress processing the requested page from scratch). It is easy to see that this basically neutralizes the functionality of the plugin. Most caching plugins and WordPress specialized hosting providers, however, ensure that caching is only intercepting requests to the WordPress front-end. So if you are using the WPO365 login plugin to offer content editors a simplified and standardized way to login to the WordPress backend you should still be able to do so, but make sure that you configure the redirect url so that it points to the WordPress backend e.g. “https://www.your-website.com/wp-admin/” (and yes, the trailing slash is important as you can read below). Please be aware that you must enter the redirect url twice:
- On the WPO365 Options page in WordPress Admin
- As Reply URL for the registered app in your Azure Active Directory
Your logon might be tampered with
When you try to logon and you’re redirected to the default WordPress logon screen and see the message Your logon might be tampered with it’s probably time to start collecting some valuable debug information. There are a couple of reasons why you may see this error, but the main reason often is a caching service or plugin serving a cached response (see previous paragraph). The system could not process the incoming ID token. In this case, please post your log files here (remove any IDs specific to your environment).
After activation the browser is stuck in a loop
There are multiple reasons why this happens. But in general it means that plugin does not detect the answer sent by Microsoft after a user authenticated successfully. So please go back to our installation instructions and read the section on how to configure the signon-url.
Ps, You can also be stuck in a loop when you use a self-signed certificate and without noticing you may unwantedly be redirected from a secure https connection to an none-secure http connection.
Login immediately after logout
If you got everything working but when you click logout you’re sent immediately back to Microsoft’s signin page and you have the All In One WP Security plugin installed then please try and deactivate this plugin and try again. We’re currently looking into this issue, but currently it’s not solved.
In general you should not see this error anymore if you use the latest version. In previous versions of the plugin it would use the App registered in Azure Active Directory to sign in the user. This required an Azure Active Directory Global Administrator to grant permission on behalf of the user. Forgetting to do so or not being able to do so because you’re not a Global Administrator would result in an access denied error. However, in the current version, the plugin requests access to Azure Active Directory instead. Now, if the Global Administrator didn’t grant permission on behalf of all users, the user himself can consent to the App reading his user information.
Access Denied (premium version)
Our premium version of the WPO365 login plugin supports Access Control based on users being a member of either an Office 365 or an Azure AD Security group. However, the Registered Apps manifest needs to modified accordingly, for this information to be sent to your WordPress website. To do so, click “Manifest” as visible in the previous screenshot. Edit the manifest as shown below.
User that is created has an incorrect email address
There are rougly three types of accounts that can log on to Azure Active Directory: Work, School and Personal. Depending on what account you use the user information that the plugin receives is slightly differently structured. For example, an MSA account (= Microsoft Account that for example ends with @live.com or @outlook.com) has a separate field for email that is missing for a work account. Currently all account types are probably supported but if you still experience this error then please contact us directly for support.