Accessing SharePoint user profile properties via REST api (_api/SP.UserProfiles.PeopleManager) in SPFx stopped working as of May 27th @ around 7pm

[tgorgdotcom]

Target SharePoint environment

SharePoint Online

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

SharePoint REST API

Developer environment

macOS

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

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

• Affecting all users in our company
• Various: Edge/Chrome/Safari latest
• SPFx version 1.17.4
• Node.js version 16.20.1
• macOS 15.4.1/Windows 11 etc

Describe the bug / error

There is an internal Microsoft support ticket attached to this.

Retreving a SharePoint user's profile properties via REST ap in SPFx stopped working as of May 27th @ around 7pm. The following code snippet will fail (mildly edited from what I have in code):

this.context.aadTokenProviderFactory.getTokenProvider();
                              .then(aadTokenProvider => { return aadTokenProvider.getToken(tenantURL) })
		             .then(token => {
				const requestHeaders: Headers = new Headers();
				requestHeaders.append("Accept", "application/json;odata=verbose");
				requestHeaders.append("Content-type", "application/json;odata=verbose");
				requestHeaders.append("Cache-Control", "no-cache");
				requestHeaders.append("Authorization", `Bearer ${token}`);
				requestHeaders.append('odata-version', '');

				return this.context.httpClient.get(tenantURL + "_api/SP.UserProfiles.PeopleManager/getuserprofilepropertyfor(accountname=@v,%20propertyname='propertyname')?@v='i:0#.f|membership|username@userco.com'", HttpClient.configurations.v1, {
					headers: requestHeaders
				});
			})

Note that I use aadTokenProvider and httpClient instead of spHttpClient because that's the only way to access properties in a multi-geo tenant. This was working for both my main domain and my emea domain.

Steps to reproduce

1. Place the above code in a newly minted SPFx webpart
2. Test the webpart with gulp serve
3. Request will fail with Permissions Denied 403 error

Expected behavior

The httpRequest should be successful and return a value for the requested property.

[Amey-MSFT]

Hello @tgorgdotcom,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

[Amey-MSFT]

Hello @tgorgdotcom,
We were able to reproduce the issue, and we are investigating it. We have logged this as a bug, and our engineering team will look into it.
Thank you!

[lucabandMSFT]

Hello @tgorgdotcom ,
the pattern you are using is undocumented thus unsupported. using SPHttpClient is the right way to go if you want to access that API directly. Alternatively you can leverage Microsoft Graph: https://learn.microsoft.com/en-us/graph/api/resources/profile-example?view=graph-rest-beta.

In regards to your comment here: "Note that I use aadTokenProvider and httpClient instead of spHttpClient because that's the only way to access properties in a multi-geo tenant. This was working for both my main domain and my emea domain."

Can you please point me where that is documented. To my Knowledge user Profile service should be GEO-independent. If you are experiencing a different behavior we need to investigate this with the proper team.

[tgorgdotcom]

Hello all. Just reiterating here what was said offline via MS Support here in case anyone else is dealing with this issue. Due to the way the browser is handling the SP cookies, cross geo requests are not working. I believe MS has now created a ticket with the multi-geo team to investigate.

[tgorgdotcom]

Just wanted to add some additional information based on our findings. Unfortunately, there are no API alternatives to access these fields. I've tried using MS Graph to access these fields such as the following commands:

https://graph.microsoft.com/beta/me?$select=fieldName
https://graph.microsoft.com/v1.0/me?$select=fieldName

These do return a 200 response code, but not the value at all. If it helps any, the fields we are selecting are not OOTB, and added via the "Manage User Properties" section in the SharePoint Online Admin.

We put in a lot of backbreaking work and sleep deprived nights resolving this by migrating data from 30k employees to MS Graph Open Extensions (to be concluded and pushed live in a few days), but I would really like to know if there was a solution that could have saved me days of work.

As an aside I do want to say the US support team was exceedingly helpful, but a lot of time seemed to be wasted waiting on the MS product team to give the MS support team and my team proper responses.

[tgorgdotcom]

Any updates on this?