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.

Before your start

To understand what causes an infinite loop it is important to understand that WordPress uses login cookies to store authentication details and limitation such as the path e.g. /wp-admin and optionally also the domain e.g. www.your-website.com. The WPO365 | LOGIN plugin, once installed and depending on the selected authentication scenario inspects each request and uses the default WordPress API to check if a user is authenticated. Basically this is accomplished by trying to find the login cookie. If  this cookie cannot be found, the plugin will redirect the user to Microsoft for authentication instead. From this it follows that an infinite loop basically then occurs when the login cookie cannot be found. Reasons why this may happen are listed below, but in general it is caused by a configuration that creates loopholes and allows users to request URLs that - technically speaking - don't belong to same domain for which the cookie was obtained. 

Recommended configuration

The recommended configuration for a single WordPress website is therefore:

Of, if you prefer a short URL:

Please note

• To change the WordPress Site URL navigate to WP Admin > Settings > General.
• To change the Azure AD Redirect URL navigate to WP Admin > WPO365 > Single sign-on, scroll down to Redirect URL and click the View in Azure Portal and make sure that you copy the exact value from Azure Portal over to the corresponding WPO365 setting.
• To change the COOKIE_DOMAIN please 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. */.

Possible causes of the infinite loop

Please note that if you have activated WordPress Multisite it is recommended to first ensure its configuration https://docs.wpo365.com/article/29-support-for-wordpress-multisite-wpmu.

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 WPO365 | SAMESITE 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 this 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.