Recently, I stumbled across a strange behavior when running self-developed SPFx webparts in various browsers. When the SPO app was deployed, it worked well with Single-Sign-On, but in some browsers, the webpart was blocked. Instead, a grey box saying "login.microsoftonline.com refused to connect." was displayed. I experienced that behavior in Chrome, and Edge, while FireFox, Safarai and Opera showed the webpart. Also, there was a different experience when working in the normal mode, or in the In-Private mode. If that happens to you, check out the solution here.

login.microsoftonline.com refused to connect

I had the described behavior when running a simple SPFx webpart that only accesses SharePoint Online resources (no Graph, no other APIs, so relatively simple). The webpart was shown as a grey box. Only when moving the mouse cursor above the box, the message "login.microsoftonline.com refused to connect." appeared. The console shows a similar message like "Refused to display 'https://login.microsoftonline.com/…' is in a frame because it set 'X-Frame-Options' to 'deny'." This message appeared in Microsoft Edge, as here.

In Edge, my browser was up-to-date and the version said "Microsoft Edge is up to date.Version 85.0.564.51 (Official build) (64-bit)".

In Google Chrome, I experienced that message on some machines, but I got that message more or less always in the Chrome In-Private mode… The version was also up-to-date: "Google Chrome is up to date. Version 85.0.4183.102 (Official Build) (64-bit)".

Find the error

The SPFx webpart worked in some situations and not in others, depending on the machine or browser version. So, it was obvious that the error had to do with browser versions or browser settings.

When doing some research, I only found closed issues in the Microsoft Techcommunity, like here or in GitHub here. But then, a colleague searched for the previous message "BSSO Telemetry: {"result":"Error","error":"NoExtension","type":"ChromeSsoTelemetry","data":{},"traces": …" in Chrome and found this issue in GitHub: AzureAD: Token silent renewal fails on Chrome only #303. User emadalsous had my solution: "In my case, it was related to a cookies security configuration in the user's browser. I had to go to Settings --> Privacy and security --> Site settings --> Cookies and site data --> set Block third-party cookies to off. If Block third-party cookies is on, it will block third party cookies, the authorization server can't be accessed in the application."

For Edge, there are similar helpful tips at techcommunity.microsoft.com and at github.com (although they are Teams-related). Find more about security settings in Edge at Microsoft Edge, browsing data, and privacy – Microsoft privacy.

The solution: Allow third-party cookies

It seems, I must allow the site microsoftonline.com to set a cookie for the login process and therefore, I need to enable "third party cookies"… So, here we go with the most common browsers.

Microsoft Edge

In Edge go to the "customize" … menu and open the "settings" and search for "tracking". Or open this URL: edge://settings/?search=tracking

Edge shows the Tracking prevention settings. By default, the setting is set to the "Balanced" mode. Click on "Exceptions" below.

Now, and add the following sites to the allowed sites:

[*.]microsoftonline.com

[*.]live.com

[*.]office.net

It seems, these rules make sense since microsoftonline.com does some redirects for the successful login process. It should look as here.

You can now click on the back icon. That´s it. The login should work now.

Note: Interestingly these settings worked for me in the Edge In-Private mode, but not in the normal mode. If you still experience the same issue, check out the article by Venkat at Microsoft Edge now blocking Third-Party Cookies In Private mode. Find also a request to improve that behavior at Microsoft Teams UserVoice. To make it short: Edge provides user profiles, but I have the impression, that the separation between user profiles simply does not work well and this caused my issue. That would explain, why this works in In-Private mode. Anyway, all other browsers worked well and instantly with the recommended cookie settings as follows.

Google Chrome

In Chrome, go to the "customize" … menu and open the "settings" and search for "block". Or open this URL: chrome://settings/cookies?search=block

Set the "General settings" to "Allow all cookies" as here.

Refresh the SPO site with the webpart. The error should be gone and the webpart should be displayed. This setting allows the site to login in the In-Private mode as well.

Firefox

Firefox works out-of-the-box with the "Standard" security settings, as here.

Opera

In Opera, the "Standard" security settings are set to "Allow sites to save and read cookie data (recommended)". This works by default.

Safari

Here´s the way to setup Safari (untested): Open "Settings" and click on "Preferences". Then, select the "Privacy tab" and deselect the checkbox before the "Prevent cross-site tracking" option. Deselect the checkbox before the "Block all cookies" option. Then exit the popup.

Internet Explorer 11

IE informs with a message "This content cannot be displayed in a frame". There might be some settings you can try, see windowsreport.com and becomethesolution.com.

In short: Forget the Internet Explorer and use Microsoft Edge including legacy app support for backward compatibility instead - or an alternative browser. Microsoft is ending support for IE this November and finally next August. See also Microsoft 365 apps say farewell to Internet Explorer 11 and Windows 10 sunsets Microsoft Edge Legacy.

Test it

When you have modified the "Third party cookie" settings, test the behavior in your installed browsers. If you care about advanced security, you can refine the settings using only the specific sites as allowed sites.

I hope this quick tip helps to see the cool SPFx webparts you have developed in all browsers and situations. Winking smile

Source: https://blog.atwork.at/post/Blocked-SPFx-App-webpart-in-browsers

SPFx App webpart is blocked in various browsers