Closed TheIronCheek closed 3 years ago
I agree this might be a timing issue. When I tested it on the page where no other web part exists other than my custom SPFx, it worked well. However, if I add other web parts document library or any other web part which also tries to obtain a token, it fails.
I start seeing this issue on my tenant from the last three weeks when we were approaching a go-live date soon. So I had to find out some solution/workaround on this.
A) Very first thing, getToken()
method promise hangs and it hangs all its successive promises. So I thought instead of Promise let’s try with $.Deferred
, but that was not adequate and there was no way to check if Promises being hanged. So I thought let’s add some waiting time for few seconds until getToken() promise completed. E.g. if we have not received resolved/failed from a promise for 5 seconds which is I believe sufficient time to find out if promise hangs (You may try by varying it depending upon your requirement) and that we considered as promise ‘timeout’ or hanged. So we can try one more time again to obtain a token, and if this ‘timeout’ as well. Then we can conclude page is loading first time and getToken() promise being hanged. So this is sufficient to take next action B)
For the above mention workaround, I made a few changes in my TOKEN class as below. This may be helpful to you to try it out.
class TOKEN {
public static getMyToken = (ctx:WebPartContext, useCached: boolean = true): Promise<any> => {
return ctx.aadTokenProviderFactory.getTokenProvider()
.then( (tP: AadTokenProvider): Promise<string> => {
return tP.getToken( "api://blablablablablablablabla" ); // For SPFx 1.9 -> return tP.getToken( “api://blablablablablablablabla”, useCached );
})
.then((token:string):string => {
return token;
})
.catch((error:any) => {
console.log("Token cannot obtained, Error details-"+error);
return null;
});
}
public static getT = ( ctx: WebPartContext, cachedToken: boolean = true ) => {
var dfd = $.Deferred();
console.log('after deferred');
// Wait for 5 seconds to check if promise hanged
TOKEN.promiseTimeout(5000 , TOKEN.getMyToken ( ctx, cachedToken ) )
.then( res => { console.log('deferred resolved'); dfd.resolve( res); })
.catch( err => { console.log('deferred rejected'); dfd.reject( err ); });
return dfd.promise();
}
public static delay( ms: number) { return new Promise( resolve => setTimeout(resolve, ms)); }
public static getAADToken = async ( ctx: WebPartContext, cachedToken: boolean = true ): Promise<any> => {
var dfd = $.Deferred();
console.log('Trying-1st');
TOKEN.getT( ctx, cachedToken ).done( tkn => { dfd.resolve( tkn ); })
.fail( async error1 => {
console.log('error1-'+error1);
await TOKEN.delay(500);
console.log('Trying-2nd');
TOKEN.getT( ctx, cachedToken ).done( tkn => { dfd.resolve( tkn ); })
.fail( async error2 => {
console.log('error2-'+error2);
dfd.reject(error2);
});
});
return dfd.promise();
}
public static promiseTimeout = (ms: number, prm: Promise<any>): Promise<any> => {
let timeout = new Promise((resolve, reject) => {
let id = setTimeout(() => {
clearTimeout(id);
reject('timeout');
}, ms);
});
return Promise.race([
prm, timeout
]);
}
}
Here is code to call the getAADToken
method from the front end.
TOKEN.getAADToken ( ctx, true )
.then( function ( token ) {
console.log('Captured Token'); // Get toke without issue onwards from 2nd time refresh
callCustomApi( token );
console.log('Call check access function');
})
.catch( err => {
console.log('token error-'+err); // timeout error as getToken hangs (First time page load)
if( err == 'timeout') {
console.log('session'+sessionStorage.getItem("adal.access.token.key"+window.location.protocol+"//"+window.location.hostname));
if(sessionStorage.getItem("adal.access.token.key"+window.location.protocol+"//"+window.location.hostname))
{
console.log('Read value form session storage');
var token = sessionStorage.getItem("adal.access.token.key"+window.location.protocol+"//"+window.location.hostname);
callCustomApi( token );
}
}
});
B) Above option just check if your promise is being failed. But we have to take the next action to get the token and pass it to a custom API, but this wasn’t working as our first promise hangs it hangs all successive promises until you refresh the page. Unexpectedly, I saw in session it returns another token which may be being requested from either doc library or any other web part. So I thought to use this token to call my API.
Fortunately, I have custom code that validates token in code behind when a custom API being called. So, I made the enhancement in my token validation code which validates this generated token as well (so it accepts and validates both types of tokens) and returns a response and getting data back on first-time page load. Following are the console log I get when the page loads first time.
This is just a workaround I am using until we get a concrete solution.
Is there an ETA on solution? We opened a premier ticket because we have it on about 5 different tenants as of last week ....
We are experiencing similar issues at multiple tenants/clients with both AadHttpClient and the MSGraphClient. Both clients don't seem to get a token. No call to the Graph or our custom API is made. We tried to optimize the size of our package but this did not fix it. The only token that is in the session storage is the one for SharePoint itself. After refreshing the page, everything works fine.
We began experiencing this issue approximately 2 weeks ago in a critical business webpart. After a lot of testing we created a new webpart with the sole functionality of retrieving a token from a tokenprovider, and then logging it to the browser console.
public render(): void {
this.context.aadTokenProviderFactory.getTokenProvider().then(provider => {
provider.getToken('MY GUID').then(token => {
console.log(token);
})
});
}
That webpart also failed.
The same webpart retrieved and printed the token as soon as the page was refreshed.
We are experiencing similar issues at multiple tenants with AadHttpClient
We're experiencing the same thing on multiple tenants, using the PnPjs graph client, this happens even with the SPFx graph sample
@andrewconnell and @VesaJuvonen could you please have a look at this issue? It is affecting multiple tenants and a large set of our customers. I strongly believe this issue should get priority from the product team.
Ping from our side. All our web parts on multiple customers are failing, using the Graph token now. Opened a premier ticket with microsoft. Fidller shows no token requests. Confirm this issue when combined with the document library web part for example, on one page.
Ping from our side. All our web parts on multiple customers are failing, using the Graph token now. Opened a premier ticket with microsoft. Fidller shows no token requests. Confirm this issue when combined with the document library web part for example, on one page.
Are you sure this is the same issue? I do see the token requests in the network tab. Problem on our side is there is only a 302 found code and no actual 200 response. So there is no actual token in the session storage for the Graph API and our custom API until I refresh the page.
Ping from our side. All our web parts on multiple customers are failing, using the Graph token now. Opened a premier ticket with microsoft. Fidller shows no token requests. Confirm this issue when combined with the document library web part for example, on one page.
Are you sure this is the same issue? I do see the token requests in the network tab. Problem on our side is there is only a 302 found code and no actual 200 response. So there is no actual token in the session storage for the Graph API and our custom API until I refresh the page.
Hello adrichema, I can confirm it's the same issue. I worked on this together with Renevdo. What we see is that most of the time, getToken() freezes, and when it freezes we don't see the request to graph. Once it worked it keeps working, and we do see requests, until we delete all storage and cookies for that site in Chrome, or maybe after some time. It seems like a race condition somewhere or a somehow cached promise that has already been fired (Made that mistake myself once)
It might be unrelated, but when I debugged this issue far into sp-pages-assembly.js, that chome message about samesite popped up like an exception. And I can confirm this only seems to happen when other webparts, like a document library are on the page.
It looks like the issue is occurring less. Does anybody agree?
It looks like the issue is occurring less. Does anybody agree?
We're unable to reproduce the issue anymore, so I would agree, it would seem there has been an update can anyone at MS confirm this?
Nope.. Unfortunately the issue still occurs on our customer tenants. We got a reply from Microsoft support and they simply pointed me to this issue. Microsoft is aware of this problem, but doesn't give us an ETA. Hope they fix this very soon, because all graphs based SPFx widgets are broken at the moment and our customers think it's out product that causes this.
It looks like the issue is occurring less. Does anybody agree?
We're unable to reproduce the issue anymore, so I would agree, it would seem there has been an update can anyone at MS confirm this?
Did you try deleting all cookies, local- and session storage for that site? That immediately reproduces the issue on our tenants.
It looks like the issue is occurring less. Does anybody agree?
We're unable to reproduce the issue anymore, so I would agree, it would seem there has been an update can anyone at MS confirm this?
Did you try deleting all cookies, local- and session storage for that site? That immediately reproduces the issue on our tenants.
Seemingly still works, did a [CTRL] + [SHIFT] + [DEL] and deleted everything from the past hour no difference.
Using Chrome v. 83.0.4103.116 64-bit on W10 version 1909 build 18363.900
Only a single webpart on the page (sample PnP Graph webpart that lists your groups)
It looks like the issue is occurring less. Does anybody agree?
We're unable to reproduce the issue anymore, so I would agree, it would seem there has been an update can anyone at MS confirm this?
Did you try deleting all cookies, local- and session storage for that site? That immediately reproduces the issue on our tenants.
Yes we tried. After deleting session storage we can reproduce the issue, but only if there is a document library webpart on the page. If we remove the webpart then the issue does not occur. when removing the session storage.
It looks like the issue is occurring less. Does anybody agree?
We're unable to reproduce the issue anymore, so I would agree, it would seem there has been an update can anyone at MS confirm this?
Did you try deleting all cookies, local- and session storage for that site? That immediately reproduces the issue on our tenants.
Yes we tried. After deleting session storage we can reproduce the issue, but only if there is a document library webpart on the page. If we remove the webpart then the issue does not occur. when removing the session storage.
We're able to reproduce the issue by adding a document library webpart to the page.
EDIT: I can't get it to work at all if there is a document library webpart, I'm not sure if these issues are related or not.
I've created a repo for my failing webpart in case anyone wants to see if they spot anything wrong. https://github.com/Tanddant/GraphProblemSample-
I can replicate the issue too.
Graph calls work fine on a page with just my custom webpart. If I add a document library web part, delete all cookies and storage data, it fails on every load.
Document library kills my web part.
Is there an ETA on solution? We opened a premier ticket because we have it on about 5 different tenants as of last week ....
@inconscienceAdmin Have you had a response from MS on this?
I've had some customers tell me this is apparently no longer an issue but I can still reproduce on my dev tenant, and other customers still see it. Are MS rolling something out?
Is there an ETA on solution? We opened a premier ticket because we have it on about 5 different tenants as of last week ....
@inconscienceAdmin Have you had a response from MS on this?
I've had some customers tell me this is apparently no longer an issue but I can still reproduce on my dev tenant, and other customers still see it. Are MS rolling something out?
@RyanHealy Yes, we had a response from microsoft. There was indeed an issue with ADAL, but a fix would be ready and rolled out by the end the week. I noticed that indeed the issue is no longer appearing on a couple of tenants, so I assume this has been rolled out or is being rolled out as we speak. :)
I'm still seeing the document library webpart killing my graph webpart on our dev environment (Targeted release).
Anyone with different results?
Here same results. But Microsoft mailed us with an ETA for at least an update: Next update by: Monday, July 20, 2020, at 10:00 PM UTC
@TazzyMan, did you get an update from Microsoft?
Hello adrichema, No, unfortunately I didn't get any mail yet and the problem still exists on our customer's tenant. I'll just give a few days. Don't know what to do the speed the process up (premier ticket didn't help), so we'll just have to wait I'm afraid.
I have a few clients who would like an official acknowledgement of this issue from MS, the last official activity on this post was on January the 8th.
Is it possible to get an official Microsoft update instead of relying on support tickets when it is not just a single tenant issue, I've tried to get MS to acknowledge the issue in a support ticket, but they simply refer me back to this thread, but my client would like something more recent (given that they only started seeing the issue recently)
I have a few clients who would like an official acknowledgement of this issue from MS, the last official activity on this post was on January the 8th.
Is it possible to get an official Microsoft update instead of relying on support tickets when it is not just a single tenant issue, I've tried to get MS to acknowledge the issue in a support ticket, but they simply refer me back to this thread, but my client would like something more recent (given that they only started seeing the issue recently)
Tuesday, July 21, 2020 5:44 AM GMT Hello Daniel, The product group has checked in some code that should fix the issue, but we are waiting on the ETA for the fix to roll out to production tenants.
I will keep you posted.
Best regards,
Westley Hall SharePoint Developer Support
So you all know. Got an e-mail from Microsoft this morning and this is the most important part:
Current status: Our fix has been validated in our internal testing environment. We're currently reviewing multiple deployment methods to mitigate impact in the affected environments due to the complex nature of the fix, and will provide an ETA on deployment once we've confirmed the most viable solution to proceed.
Next update by: Friday, July 24, 2020, at 10:00 PM UTC
Hi,
Just wanted to give some context regarding the issue and fix.
SPFx has been relying on ADAL.JS to fetch AAD tokens for 1st & 3rd party experiences. We found a race condition that was exposed by ADAL.JS's Authentication Context object being initialized on the same page multiple times. The race condition could not be patched, so a complete rewrite was done to avoid this & other potential pitfalls of using ADAL.JS. As you can imagine, this is a non trivial amount of code, so we want to give it as much bake time as possible to avoid creating a bad experience. The code should be rolling out slowly over the next couple of weeks.
This rewrite uses the Implicit Flow for acquiring AAD tokens, similar to ADAL.JS/MSAL.JS. We're working closely with the AAD team to move to MSAL 2.0, which we're expecting to have huge improvements in terms of performance and reliability.
Hello, are there any updates on this issue?
We are experiencing issues with AadHttpClient in our SPFx web parts that consume Azure AD-Secured APIs. The first time user accesses a page with an SPFx web part that consumes an Azure AD-Secured API it works fine. But after a period of inactivity like 30 mins, if the user tries to access the same page or another page with another SPFx web part that makes an Azure AD-Secured API call the request fails with a 401 unauthorized error. Based on our troubleshooting, the AadHttpClient is still using an expired access token from a previous session. The older access token gets cached and there is no way to get out of this. Closing the browser or clearing browser cache doesn't resolve this issue. This is the same behavior in new Edge and Chrome.
SharePoint Online REST APIs are working fine. We have a few pages that have multiple web parts and the web parts consuming SPO APIs are working fine but the ones consuming Azure AD-Secured APIs are failing.
We are currently experiencing production outages due to this issue. A critical case was opened with Microsoft yesterday but seems like we are having very hard time trying to get to the product team. This is absolutely frustrating as our hands are totally tied and we are not getting much help from Microsoft.
@lahuey Is there an easy way to see if the update is rolled out to us? I can see that spfxsinglesignon.aspx is still referencing adal.js on our tenant (assuming this is indeed the utility page that handles SPFX redirectUri and places tokens into session storage).
We are also experiencing this issue! After 30 minutes of inactivity all calls to the Graph and our own Azure AD protected API are failing with 401 errors. CRTL + F5 does not help! Only closing the browser and restart seems to fix the issue. This is very inconvenient.
We are seeing the same behaviour as @adrichema and @jkondakindi are describing. Any updates on this issue?
Hi all, We got an e-mail from Microsoft that indicates the problem should be fixed now. Tested yesterday on the clients environment and seems to work now.
As the OP, it appears that the issue has been resolved almost everywhere for me.
I'm still getting issues in the old non-Chromium Edge, though. My web part doesn't work at all there. It just hangs.
@lahuey @andrewconnell - Anything word from MS about whether the issue is actually resolved, if the fix didn't include support for the older Edge, or if I'm just having an additional non-related problem?
@TheIronCheek I can't say... I don't have any additional insight. Might take a look at this: https://github.com/SharePoint/sp-dev-docs/issues/6135#issuecomment-681001868
Worth noting non-Chromium Edge is on death row...
We are facing this issue where token gets expired after 60 minutes approx. and then we have to close the browser to get the refreshed token. We are using single app part page with SPFX. So there is no other OOB web part on the page. Any help?
Is anyone still having the original issue? I haven't run into it since before @TazzyMan posted his response from MS saying it's fixed. I was hoping for something official from @andrewconnell saying MS had indeed addressed the issue but assuming no one else is having the issue, I'll go ahead and close this.
@asim-bashir-confiz - It sounds like a different issue. Our issue happens only when a custom web part is on the same page as an OOB web part.
@TheIronCheek Andrew closed a bug that described the issue that @asim-bashir-confiz has (and I also have) as a duplicate, that's why I'm still watching this thread
Didn't get any complaints from our customer anymore. Either they gave up or it's fixed now.
We are still facing the above issue. it's not resolved yet in our tenant. Do let us know if you need any more information about the same.
@umarokeeffetrade @OmAlim @asim-bashir-confiz
See: https://github.com/SharePoint/sp-dev-docs/issues/4892#issuecomment-682105898
We are facing the same problem that @umarokeeffetrade @asim-bashir-confiz are referring to.
Since we don't have an ETA from MSFT, is there a workaround that we could use (till MSFT deploys the fix on our production tenant)? I wonder if there is a way to silently request a new token before the existing one is about to expire? Not ideal but atleast it will reduce the annoyance for our users who, right now have to close the browser tab in order to access the application once the token expires.
it's really weird that this is not yet resolved after all those months;
we have implemented custom events in app insights (exclusively just to measure annoyance of users) and on our tenant ~10% of 'data loads' in our components ends with 401 unauthorized error (from graph api - MSGraphClientFactory and custom api hosted on azure - AadHttpClient);
as a workaround we added sessionStorage.clear() and a request to the user to refresh the page in error messages;
I'm wondering how it looks in internal MS logs - I bet that majority of 401's is a result of this issue here and not 'real' unauthorized access;
anyway I hope this will be fixed soon...
is there any updates from MSFT of the fix deployed on all tenants. How it can be verified whether the fix is available on a tenant? Anyone still facing race issue even after the fix available?
Was this issue solved ? We still see the same behavior.
It seems like we have a similar issue. Was it deployed to all tenants? How can I check whether our tenant has this fix?
Token retrieval timeout
Error: Token retrieval timeout at https://spoprod-a.akamaihd.net/files/sp-client/chunk.spoImplicit_none_0381f45b4fba0f3b19df.js:1:3485
on and on today...
AFAIK the currently deployed patch (using MSAL 1.x) should not be having an issue regarding expired tokens which are not resolved properly (which was the case with the old/previous ADAL version).
In all of our clients i see the MSAL implementation is active (check if you see there are any msal. entries in your sessionStorage). If you still see adal. entries, the old ADAL implementation is still active for your tenant.
You can still face concurrency issue's when you have multiple webparts each requesting tokens for the same resource scope (besides it is not efficient). I have solved this by creating my own library (based on MSAL v2).
Indeed on our tenant we see only ADAL in session storage - not a single MSAL. What can we do from your side ?
Category
Expected or Desired Behavior
The promise returned by AadTokenProvider.getToken() should always resolve or reject. In other words, when a token can't be retrieved for whatever reason, I should get something back that I can catch.
Observed Behavior
getToken()
is occasionally hanging - never resolving or rejecting so I can't catch an error or figure out what's happening. The .then() undergetToken()
just never runs and my web part stalls.Steps to Reproduce
I'm trying to access a .NET Core Web API secured with AAD from my custom web part. I initially used the instructions found here but
AadHttpClient.get()
was occasionally stalling so I decided to get the token usingAadTokenProvider.getToken()
and manually add it to aHttpClient.get()
but my issue didn't go away. I was however able to confirm thatgetToken()
is where it hangs rather than an issue with the API. Here's my code:I noticed that it seems to hang after a period of inactivity like maybe it's failing to refresh a stale token or something. I'd expect the rejection code to execute but nothing beyond
getToken()
runs. But if I refesh the page a couple times, it starts working again.This seems to be related to issue #914 reported on pnp/pnpjs.
Edit: I discovered that this is a lot easier to reproduce in Chrome. (I haven't seen it occur in IE and I've only seen it once or twice in Firefox although I can't seem to reproduce in FF at the moment. Edge gets the token but fails the API request for reasons I can't explain). In Chrome, it struggles every time it needs to grab a token. So, for example, it hangs the first time you load the page. If you refresh a few times, it starts working. Then if you leave the page open for a period of time (long enough for the token to expire) and refresh the page, it hangs again.
Edit 2: Per the conversation below, we can reproduce the issue when the custom web part is on the same page as a document library and a planner or events web part and it works fine when on a page by itself. There may be some sort of conflict with token retrieval/sharing between web parts.