Pnpjs: Graph cookie on SharePoint is saved under the same variable as default SharePoint webparts do

[pkmelee337]

Category

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

Version

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

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

Expected / Desired Behavior / Question

I have implemented the pnp/pnpjs library in an SPFx webpart I'm creating. After deploying the webpart to SharePoint I have added it to an modern page with an SharePoint webpart already on it. (Recent Documents) This SharePoint webpart also uses Graph to retrieve it's document.

In my own webpart I am using our own Azure Ad Registration as followed:

let adalClient = new AdalClient(
    '<our own clientId>',
    this.pageContext().aadInfo.tenantId.toString(), // pageContext() is the pageContext retreived from the webpartcontext
    `${window.location.protocol}//${window.location.hostname}/_forms/spfxsinglesignon.aspx`,
);

graph.setup({
    graph: {
        fetchClientFactory: () => {
            return adalClient;
        },
    }
});

When deployed like this I am expecting my webpart to be able to retrieve my skills from graph, like it does on a page without a SharePoint webpart added to it.

Observed Behavior

What happens is that the graph request on my webpart are failing with an token renewal failed error. When debugging this a little further it seems like this is due to the fact that I am using the resourceid https://graph.microsoft.com to send requests to the graph. (this is automatically done by pnpjs) The SharePoint webpart is doing the same, but with another client id (the default SP client id). The token which is retrieved, is saved in the session storage under a property "adal.access.token.keyhttps://graph.microsoft.com".

This means that the webpart which authenticates first, is saving this token, and every other webpart using Graph will use this token. That means that if I have an SharePoint webpart somewhere on SharePoint, and I am going to this page, all the SPFx webparts using Graph I created myself won't work untill this webpart is removed. The other way around is also happening, altough this is not a problem for me at the moment because our Azure AD registration has enough permissions for the SharePoint webparts to work a.t.m.

At this moment I'm a little unsure if this cookie is saved by pnpjs or by SharePoint on the redirect page. If the latter is the case, this might also be a bug on the /_forms/spfxsinglesignon.aspx page.

Steps to Reproduce

1. Create a webpart using Graph with your own Azure AD registration (see code aboven, make sure you retrieve something which is not included by default in the SP default Azure AD registration described here)
2. Add and SharePoint default webpart to a modern page which also consumes Graph and load the page once in a new session. (for example Recent documents)
3. Add your own webpart to the same or another page and load it in the same session you've loaded the SharePoint webpart.

[patrick-rodgers]

Unfortunately, this is all controlled by adal.js. We don't store any cookies/session storage ourselves. I am not sure we could control this or that it is desirable for us to try. It derives from their internal design of that library which acts as a global singleton. My guess is that when they designed it they only considered the user case of angular which is a SPA and in their use case had a single associated id.

If you are operating withing SharePoint Framework I would recommend centralizing on the SPFx app and granting all the permissions you need there. Then you can use the AADTokenProvider and other new clients for graph in 1.6. We will with the next release of pnpjs make use of these capabilities as well through the ADALClient.fromSPFxContext method.

[pkmelee337]

Thanks for the fast reply. I was afraid this would be the case, haha. I did consider centralizing around the SPFx app, but the problem with this app is that if I would give it permissions to do something, everyone creating an SPFx webpart would have this permissions. This is something some of our customers won't accept for sure. (explained further in this issue on the sp-dev-docs github) Therefore for now we are still using our own clientId until a solution is provided for this problem. I guess we will have to wait untill the MSAL library will get implemented, because I don't think the adal library will any get changes anymore.