Infinite loop

Use this guide to help find the root cause of why the plugin keeps sending you to Microsoft, even though you successfully signed in with your corporate or school account.

How the plugin works and why the infinite loop may actually be a good sign 

The infinite loop - in most cases - is basically a result from the plugin simply doing its job. It intercepts and inspects each incoming request. And when it does, it checks the WPO365 configuration to understand whether or not the user should authenticate in order to see the requested page. If this is the case and the user is not signed into your WordPress website, it will redirect the user to Microsoft. Once the user signed in with Microsoft, he / she will be sent back by Microsoft to your website (more specifically, to the URL that you configured as Redirect URI) and again the plugin will inspect the incoming request. It will search for a so-called authentication response. If it finds such a response - the so-called ID token - it will try to sign the user into your WordPress website. Once the user is signed into your website the plugin will redirect user to the URL he or she initially intended to load.

Possible causes of the infinite loop

1. Your website is reachable using multiple URLs

In case you have configured a short URL for your website e.g. https://your-website.com but do not redirect users that try to access your website via https://www.your-website.com to the short version your users probably end up in an endless infinite loop.

What happens is that the user will receive a WordPress authentication cookie for one domain - namely the domain that corresponds to the domain of the Redirect URI - and then is redirected by the plugin to the URL that he / she initially requested, which may be not the same domain. Therefore WordPress does not see the authentication cookie and the plugin will restart the authentication flow.

Follow these steps to prevent this type of infinite loop.

  • Choose your preferred website domain e.g. https://your-website.com and add a rewrite rule to your .htaccess file that would redirect users that try to visit https://www.your-website.com to https://your-website.com.
  • Make sure that the Redirect URI that you have configured in Azure AD for your WordPress website's App registration is has the hostname that corresponds to your preferred hostname.
  • Make sure that the Redirect URI that you have used for the corresponding setting on the plugin's Single sign-on configuration page is exactly the same as the one used for the App registration.
  • Edit your wp-config.php file and add the line define('COOKIE_DOMAIN', 'your-website.com'); just below the line that reads /* That's all, stop editing! Happy publishing. */ (obviously you would need to replace your-website.com with your own domain).
  • Last but not least you should verify your website's WordPress Address (URL) and Site Address (URL) when you  navigate to WP Admin > Settings > General. In case of WordPress Multisite you may need to change these addresses directly in the database instead.
2. Your website is reachable using different schemes

To use Azure AD App registration your website must use SSL. As a result your website address in all cases start with https://... and you must make sure that user cannot access your website via the non-secure http://... scheme. If you haven't prevented users from accessing your website using the non-secure scheme it is possible that the user is in fact signed into the secure version of your website but when he or she navigates (back to) the non-secure version the login information in the form of a WordPress cookie is not found and the plugin starts the authentication workflow.

Tip As a remedy, try to install and active the Really Simple SSL plugin from the WordPress plugin directory (see https://wordpress.org/plugins/really-simple-ssl/ for details). It will help ensure all traffic gets redirected to HTTPS plus it will help fix your general WordPress configuration such as WordPress Home and Site Address URLs.

3. The authentication response is dropped

It is possible that the authentication response, added to the request by Microsoft when the user authenticated successfully, is dropped when the user is being redirected back to your website. There is not one particular reason why this may happen e.g. a load balancer may redirect the user but not pass on all headers or an additional redirect occurs and the authentication response is simply dropped. In such cases the authentication will never make it to the plugin and thus the plugin will start the authentication workflow from scratch.

Last but not least Finding the root cause of this problem is not easy. Very often it has proven valuable to analyze the network traffic. To do so you can use for example your browser's developer tools. In Chrome press F12 to open the developer tools and activate the Network tab. Check the Preserve log option and navigate to your website and reproduce the infinite loop. Once the loop occurred, stop the browser from loading and carefully analyze the traffic and search for signs of any of the aforementioned possibly causes. If you can not find the cause then please feel free to download the network log as a HAR file and send it to support [@] wpo365 [.] com.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.