search

SharePoint / sp-dev-docs

SharePoint & Viva Connections Developer Documentation
https://docs.microsoft.com/en-us/sharepoint/dev/
Creative Commons Attribution 4.0 International
1.24k stars 998 forks source link

"Application requested a user session which does not exist" and "Token request previously failed" #9325

Open kbeeveer46 opened 9 months ago

kbeeveer46 commented 9 months ago

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

Additional environment details

Describe the bug / error

I know these 2 errors have been talked about a million times on here before but I've tried all the solutions that usually work and they are not working this time. When our clients have gotten these errors in the past it's always related to cookies. So this time around I had the client do the same thing as our previous clients that had the same issue.

But they keep getting those 2 errors no matter which browser they try. The error is occurring on the second line of the code snippet below. I have this code in a while loop that tries to get the token 3 times in case it fails (we've been having problems with the getToken method for various reason over the years). It fails all 3 times.

The client is able to view the SharePoint site so that tells me all the permissions are working correctly. The issue is happening after the page loads when we try to generate a token to use with our API calls to the database to load data on the page. So it has to be something on the client's end like an issue with cookies or a browser setting.

Am I missing any possible solutions? Can someone look inside that library and let me know all the reasons the code would spit out the "Application requested a user session which does not exist" error? It's almost impossible to fix the issue when I have no idea what causes the error.

EDIT: I was able to reproduce the exact same errors in the workbench in Chrome by blocking third party cookies. But what I found is that sometimes the page DID NOT do a full page reload to attempt the workaround/backup authentication when cookies are blocked. I think this may be the cause of the issue for the client. I think the authentication is failing and the backup option is also not working. It doesn't explain why they would be getting the errors in the first place when their IT staff said they changed the settings to allow cookies.

EDIT 2: We now have a second client who has the same issue.

EDIT 3: It seems to work for client 2 now. I had them do all the same steps as client 1. The issue is definitely related to cookies but it's hard to tell what actually fixes it. Maybe wiping all cookies is the thing that fixes it and client 1 didn't do it correctly.

EDIT 4: We're up to 5 clients now who are showing these errors in our logs within the past week. Was there a recent change behind the scenes regarding tokens? We're seeing the errors from Edge, Chrome, and Safari. All different clients.

Steps to reproduce

const provider = await this.context.aadTokenProviderFactory.getTokenProvider();

token = await provider.getToken(Settings.AZURE_SHAREPOINT_APP_REG_CLIENT_ID) ?? "";

Expected behavior

Return a token

ghost commented 9 months ago

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

andrewpeterson99 commented 1 month ago

@kbeeveer46 did you ever figure this out? I'm running into the same issue.

andrewpeterson99 commented 1 month ago

Pinging @nick-pape as well for this.

kbeeveer46 commented 1 month ago

@andrewpeterson99 We have 1,400 external guest users that log into our SharePoint which we use for our client portal. We require the user to set up MFA with the auth app, phone call, or text message option.

I wish there was a place that explained all these errors. I have a list of 15 or so errors that Microsoft throws during SSO authentication and token generation (both single points of failure) and I can't tell if they are just informational or blocking things from working. The only ones that I know of that stops everything from working are the token errors above.

andrewpeterson99 commented 1 month ago

Thanks so much for dropping an update @kbeeveer46. The situations we're seeing this error in is also rendering our Sharepoint integration completely broken. The strange thing is that we have only a subset of customers seeing the issue, but those that do encounter it cannot seem to get rid of it (e.g. the users who have the problem can't stop having the problem). Is this the behavior you're seeing on your end as well?

kbeeveer46 commented 1 month ago

@andrewpeterson99 Since the last time I commented we've gotten the "Token renewal operation failed due to timeout" error once from a user within our company and 3 times from an external guest user (external user got them all within the same minute/browsing session).

According to our logs, the external user viewed our SharePoint site earlier in the day and didn't get the error. It only happened when they visited again later in the day.

I haven't found anything in common when the error happens. It happens for random users and when it happens it doesn't happen every time for that user.

andrewpeterson99 commented 1 month ago

I may have made some progress on a fix, but I haven't been able to get a customer to verify the efficacy yet. I can repro the issue consistently for failing JWT requests if I don't grant all the API permissions in Sharepoint (specifically, access_as_user). The API permissions page for Sharepoint seems to be a bit buggy/have race conditions, as the UI there doesn't always reflect what's present in Azure for the app registration. Here are the steps I wrote up for our customers:

You could try this in the instance where your internal repro occurred and see if it fixes it? Some direction from @nick-pape or MS on this would be super appreciated.

kbeeveer46 commented 1 month ago

@andrewpeterson99 I'm not sure what "access_as_user" is. We do not use a permission by that name. Is it the same thing as user_impersonation? The app registration that our SharePoint webparts use to make API calls and generate tokens has the user_impersonation permission (and User.Read). The permission is listed under the app registration image

It's also under the approved list on the API permission page (the link in your 5th bullet point) and in the package-solution.json file in our app

"webApiPermissionRequests": [          
            {
                "resource": "ClientPortalSharePointAPI",
                "scope": "user_impersonation"
            }
        ]

It looks like our scenarios might not be the same but resulting in the same error message. I don't have permissions to approve API permissions so I can't run your test.

andrewpeterson99 commented 1 month ago

Here's a link that makes it sound as though we just have different custom names (and the checking against them is what matters more than the name itself): https://github.com/Azure-Samples/active-directory-dotnet-native-desktop/issues/36