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. When you load your WordPress website inside an iframe / Microsoft Teams App or Tab

Begin 2020 Chrome launched with new default settings for the SameSite cookie attribute. These changes may dramatically impact third-party cookie tracking, loosely akin to Safari's ITP. Previously, when the SameSite cookie attribute was omitted, browsers would share cookies with no domain limitations and thus third-party cookies could fire (is SameSite=None). Nowadays, more and more browsers only share cookies without a SameSite attribute when the domain in URL bar equals the cookie’s domain (first-party, is SameSite=Lax).

Basically this means that loading your WordPress site inside an iframe or as an App or a Tab in Microsoft Teams in a browser is still possible as long as you do not require your users to sign in to view (private) pages and posts. If you do require users to sign in (e.g. with Microsoft with the help of one of the WPO365 plugins), however, then you may notice that this is impossible because the WordPress authentication cookies are by default no longer included by the browser. As a result the WPO365 login window keeps popping up.

To overcome this problem you can try to install the WPO365 | SAMESITE plugin. It will override the pluggable WordPress function wp_set_auth_cookie to always set SameSite=None to enable third-party usage of cookies.

Perform the following steps to install the plugin:

  • Go to WP Admin > Plugins > Add new and search for WPO365.
  • Click Install to install the plugin.
  • Click Activate to activate the plugin.

2. 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.
3. 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.

4. 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.