Pnpjs: Access denied exception in case account is a member of multiple tenants

[nbelyh]

Category

• [ ] Enhancement
• [ ] Bug
• [x] Question
• [ ] Documentation gap/issue

Version

Please specify what version of the library you are using: [2.0.12]

Please specify what version(s) of SharePoint you are targeting: [SharePoint Online]

Question

When your account is a member of two tenants, and you are logged in two sites (you have two browser tabs next to each other) then if you call any API in the first tab, then switch to the second tab, and call any API there, you'll get access denied.
Is it possible to avoid this?

This seems to be reproducible even with plan SharePoint though (modern pages):

• Open some list in the first tab (first tenant).
• Open some list in the second tab (second tenant).
• switch to the first tab. Sort the list
• switch to the second tab. Sort the list ⇒ something went wrong ("broken bike" icon), in the log you have access denied. It will stay like this until you reload the page.

Preconditions:

• There are two different tenants (organizations)
• You use the same account to access both (and saved credentials)
• You have the sites opened in the same browser (two tabs), with "remember me" option set.

In this case activating one tab and then doing any request in the tab leads to access denied in another tab (until you completely reload the page). Would be really grateful if someone could explain the reason why this is happening, or suggest a workaround.

[koltyakov]

Hi @nbelyh, I have concerns that this is on the side of the library. When being on a SharePoint page PnPjs sends requests without any authentication flow involved. The request ends up natively pre-authenticated fetch with an auth cookie not managed by us.

Sort the list ⇒ something went wrong ("broken bike" icon)

This isn't something related to PnPjs library but the OOTB list UI and any resource or API request in SharePoint as a result of logging in to different tenants. To my ear, the native UI will behave this way, and logging in will be required.

It's likely that such a scenario is just not supported. I'd use different browser profiles for different tenants to avoid auth issues.

[nbelyh]

@koltyakov Thank you for the prompt response!

If authentication is completely outside the library, then this is definitely not the right place to ask... Looks like stock behavior of the API. Probably need to investigate a bit more to ask in a right place.

I mentioned the stock behavior as a possible hint to understand what's going on in this case. The thing is now each tab is has own process right (Chrome) so how does it even know that I have just done something in another tab?

[koltyakov]

If authentication is completely outside the library

To be clear on this statement:

• When deployed to SharePoint (SPFx solution) and the requests are sent to SharePoint APIs - no additional managed auth.
• If a request is sent from Node.js, to Graph, or from the non-SharePoint page to SP/Graph API from within ADAL/MSAL app - these are the cases we can manage authentication.

I mentioned the stock behavior as a possible hint to understand what's going on in this case. The thing is now each tab is has own process right (Chrome) so how does it even know that I have just done something in another tab?

Cookies/local/session storage will be updated when an update has happened in another tab. These guys are scoped to the domain though. So the behavior anyway is strange.

[nbelyh]

@koltyakov Exactly. The domains are different! (but both are **.sharepoint.com) A short clip showing the issue with built-in UI:
https://unmanagedvisio.com/upload/switch-sites1.gif