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.25k stars 1.01k forks source link

SPFx AadHttpClient fails in Teams App on iPhone #9014

Open arnoldmatusz opened 1 year ago

arnoldmatusz commented 1 year 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

Everything works fine in the Teams App on Windows, in the Teams App in a browser, in a SharePoint Page or even in the iOS SharePoint App. Furthermore everything works fine on an Android Teams App.

The issue doesn't seem to be related to the Teams App on iOS in general, as we we have multiple iOS devices where we can use the functionality without any problems.

Describe the bug / error

Our functionality is added to Teams as a personal app or as a Teams Tab, both don't work on the device setup statet above.

We need to load some data from a specific URL (the URL is an Azure App Service with authentication against our Azure AD). When using AadHttpClient to send requests to a certain service, the first request after the deployment of a fresh package succeeds, but all subsequent requests neither resolve nor reject the Promise returned by the .get() method.

Steps to reproduce

Here's an example of our code:

aadClient = await this.context.aadHttpClientFactory.getClient('the id of the correct App Registration');
aadClient.get(serviceUrl, AadHttpClient.configurations.v1)
    .then((res: HttpClientResponse) => {      
      console.log('data received');
    })
    .catch((error: any) => {
      console.log('error occurred');
    `});

Neither the then nor the catch area will be called, hence no console logs will be written.

What is very notworthy: the functionality works fine the first time after we deploy a new SPFx page. In this case we can also see a request being made to generate an authentication token. On any subsequent requests, this is not the case.

Expected behavior

Generally speaking, this functionality has been in use for the last 3 years, working just fine on all devices. As stated above, the functionality only fails of some iOS devices.

ghost commented 1 year ago

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

arnoldmatusz commented 1 year ago

As our customers can't use their iPhones with our app, this issue has a very high priority for us and our customers. Thanks in advance for taking a look.

arnoldmatusz commented 1 year ago

An update to SPFx version: 1.17.4 didn't change the behaviour.

arnoldmatusz commented 1 year ago

New info about the behaviour: today we found out, that the behaviour is only connected to the device and not to any user. We used multiple users to log in on an iPhone 13 Pro, where it didn't work (just as documented above) for all users. But we can flawlessly use our functionality from an iPhone 12 with multiple users.

arnoldmatusz commented 1 year ago

New info about the behavior: until now, we were able to see our functionality working every first time after the SPFx Package is deployed. We have now seen the same behavior after a language change on the iPhone. First load after a language change - everything works as expected. Second and every subsequent load the webservice call is never answered.

AJIXuMuK commented 1 year ago

@arnoldmatusz - thanks for all the updates. We're investigating the issue and need some extra info if you could collect/provide it.

It would be great if you could collect a network trace for the app loading for both working and non working devices.

To collect the trace, you can install Proxyman. You will also need to add .sharepoint.com and login.microsoftonline.com in SSL Proxying list to decrypt the request and response.

You can send the trace to aterentiev@microsoft.com

ghost commented 1 year ago

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within the next 7 days of this comment. Please see our wiki for more information: Issue List Labels: Needs Author Feedback & Issue List: No response from the original issue author

arnoldmatusz commented 1 year ago

@arnoldmatusz - thanks for all the updates. We're investigating the issue and need some extra info if you could collect/provide it.

It would be great if you could collect a network trace for the app loading for both working and non working devices.

To collect the trace, you can install Proxyman. You will also need to add .sharepoint.com and login.microsoftonline.com in SSL Proxying list to decrypt the request and response.

You can send the trace to aterentiev@microsoft.com

Response sent to your email. Let me know, if there is anything else I can do. Thanks.

arnoldmatusz commented 1 year ago

As more and more users are affected by this issue, can you give us any feedback for this please? Thank you in advance. @VesaJuvonen @AJIXuMuK

danielcostalvt commented 1 year ago

@VesaJuvonen @AJIXuMuK I believe this is also tied with the ITP of iPhones or any 3rd party cookie protection. Similar to the issue I've opened here https://github.com/SharePoint/sp-dev-docs/issues/8881

It is highly needed an answer from microsoft on how they plan to tackle this in a more definitive way. Though the popup flow (which is still not working) is a first step, in case of multiple calls to different apis, we get flooded with popups, which leads to a bad experience.

Can you please provide some insight as to what we can expect as resolution here?

arnoldmatusz commented 1 year ago

Updating to SPFx 1.18 didn't change anything.

@VesaJuvonen @AJIXuMuK - why doesn't this issue get a little more attention? While SPFx is being promoted heavily, we are having this issue for months without any considerable feedback. Furthermore we have customers, whom we can't give any kind of relevant workarounds for the mentioned devices. Can you please give us some feedback here.

Thank you in advance!

lucabandMSFT commented 1 year ago

Hey @arnoldmatusz, thanks for reaching back (again).

We were able to finally do some tests on our side and confirm that we cannot repro the issue on anything newer than an iPhone 13.

Can you please, if it is possible for you, confirm this? At this point we believe this to be an iPhone problem... which leaves unfortunately little room from our side to operate.

arnoldmatusz commented 1 year ago

Hey @lucabandMSFT , thanks for your response.

I'm not quite sure how to interpret your response. Did you only test on iPhones newer than 13 and you can't reproduce or you can reproduce the issue on older ones and not on any newer ones?

Ultimately it doesn't make much of a difference. The problem exists at multiple customers and we won't be able to tell them to change their phones, just because our app won't work on them.

I have to add that everything works well, first time after any fresh spfx solution deployment, hence the setup is fine, and everything works as it should in principal, just like it did for over 2 years. I feel like there has to be more, that can be done here.

Furthermore, I can't imagine that Microsoft can happily accept that this issue exists out there and that a fairly new phone model will not work with SPFx in an SSO context?

Why can't somebody take a look at this live, I'll happily demo everything described above ... if needed I'm also available for giving out a user account, so that you can test using our environment.

Happy to hear from you soon, thanks in advance.

arnoldmatusz commented 1 year ago

Hi @lucabandMSFT, @VesaJuvonen, @AJIXuMuK,

as we are stuck here ... and because our customers are making lots and lots of pressure we are trying alternatives.

First thing we tried, is to use the "AadTokenProvider" to get us a token, which we will use in the Header of the requests towards our web services. I'm quite sure that this is what happens behind the scenes, when this is run. aadClient.get(serviceUrl, AadHttpClient.configurations.v1)

But we wanted to try it for ourselves. So here's the code ...

try {
  const tokenProvider: AadTokenProvider = await this.context.aadTokenProviderFactory.getTokenProvider();
  this.properties.token = await tokenProvider.getToken(azureClientId);
} catch (error) {
  console.log(error);
}

Technically speaking, everything works exactly like before ... everything works on desktops, andriod devices, iOS devices, except for the models stated above. So no real change.

We can confirm, that the following line this.properties.token = await tokenProvider.getToken(azureClientId); will never respond on an iPhone 13 Pro (apart from the first run after a fresh deployment).

I'd love to show anybody, everything stated above in a live demo, I'm looking forward to your contact. Thanks in advance.

lucabandMSFT commented 1 year ago

Hey @arnoldmatusz, We were able to repro the issue on iPhones 13, but no longer in never versions of iPhones.

The thing that is honestly baffing us is that, from our point of view there's nothing that changes. What I mean by that is that there's nothing in our code (SPFx) that behaves differently if the device is one version vs. another one.

What we are seeing is that TeamsSDK getAuthToken hangs there and doesn't return any token. And because we do not timeout, the code simply stays there waiting for getAuthToken to resolve. In some situations we have seen Teams taking up to 2 minutes before returning the token. Out of curiosity, have you tried to wait up to 2 minutes to see if the promise resolves? Mind that I'm not saying that how it should work: I totally agree with you that, even if that work, is not acceptable. I'm just trying to get as many data points as possible.

Now: why that is happening only on iPhone 13 and not newer phones? That's what we are working on to figure it out. Give us couple of additional days as we are trying to figure out what's going on in Teams stack.

I will provide an update here as soon as we have news.

arnoldmatusz commented 1 year ago

Hi @lucabandMSFT

thanks for the info.

It's the same for us. The amount of effort we have invested to analyse this, is simply enormous. The most peculiar behaviour from our point of view (besides the fact, that the same code basis will work on one device and not on another) is that the code will work the first time after a fresh deployment on any device.

Regarding your question ... we have tried everything, we have tried waiting (even more than 2 minutes) but the result never came.

Is there anything we can do for you? Do you want us to take a look together? Thanks @lucabandMSFT

arnoldmatusz commented 1 year ago

Hi @lucabandMSFT, @VesaJuvonen,

with further customers beeing impacted, I wanted to ask, if you have any news on this. Thanks in advance.

arnoldmatusz commented 11 months ago

Hi @lucabandMSFT, @VesaJuvonen

our customers report that newer iPhone models are affected (iPhone 14, iPhone 14 Pro, iPhone Pro Max, iPhone 15, etc.) aswell. This adds a criticality, we didn't have before.

While I enjoy the whole SPFx journey, it's very dissapointing not to get any attention and support for something that is this important. What are the alternatives here, as ignoring so many mobile modells is not an option?

Thanks in advance.

lucabandMSFT commented 11 months ago

Sorry for my delay in answering, but I didn't have the opportunity to get any help from other teams.

@arnoldmatusz , does any of your customers have any support contract in place so that they can open a support request with Microsoft? that would be the fastest and more reliable way to follow up with this problems as the support team can also help the customer collecting Teams mobile logs that are critical for the investigation.

Thanks and regards, Luca

gauravkeshre commented 11 months ago

Hi @arnoldmatusz I am from iOS Platform team. I tried to reproduce this issue with a sample SPFx app on iPhone 15 simulator and iPhone 12 device but in vain. Can you please help us with following details so that we can investigate further:

  1. iOS Device logs
  2. Test account creds where we can reproduce this.
arnoldmatusz commented 11 months ago

Hi @gauravkeshre

I will gladly provide you with credentials where you can test, but first I would like to show you the issue live. Please contact me at "arnold at matusz dot de" for a short meeting. Thanks in advance.

gauravkeshre commented 11 months ago

Sure, I am checking internally how we can facilitate a call for you. In the meantime, I kindly request you to "Shake and send" the logs so that we can assess if we need to involve any other team in the call.

lucabandMSFT commented 10 months ago

@arnoldmatusz , happy 2024. Was wondering if you were able to "Shake and send" the logs as requested by @gauravkeshre

Thank you

ghost commented 10 months ago

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within the next 7 days of this comment. Please see our wiki for more information: Issue List Labels: Needs Author Feedback & Issue List: No response from the original issue author

arnoldmatusz commented 10 months ago

Hi @lucabandMSFT, @gauravkeshre I can't find the shake and send feature on my iPhone ... in a previous attempt, I've sent some proxyman logs to @AJIXuMuK. Is that of any interest to you?

Furthermore, I think a short MS Teams call on would showcase quickly and exactly what is wrong.

Thanks in advance.

arnoldmatusz commented 9 months ago

Any news on this guys?

arnoldmatusz commented 9 months ago

Hi @lucabandMSFT , @AJIXuMuK, @VesaJuvonen , @gauravkeshre An update to 1.18.2 didn't change anything.

Can we please have a short meeting, where I can showcase what happens and I can also hand over user accounts which you can use for internal analysis and tests.

danielcostalvt commented 8 months ago

@lucabandMSFT @VesaJuvonen I have a few questions on this solution: -Is this the Long Term solution by Microsoft? Iā€™m concerned that as blocking cookies become a market practice, the UX of all SharePoint customers will suffer drastically from this approach. -If not the Long Term solution, what are the alternative paths being considered and what are the timelines? -How this impact Page Views / App Insights analytics? Will it count twice because of the reload?

arnoldmatusz commented 8 months ago

Hi @lucabandMSFT @VesaJuvonen and @AJIXuMuK ,

after a cumulative effort of many many months we have now found the culprit. I can't really explain why it happens but here's what we have found.

When we remove this code from our onInit method everything begins to work as we need it to.

await app.initialize().then(async () => { await app.getContext().then(context => { this.inTeams = true; }).catch(() => { console.log("app.getContext() failed, page is called outside teams"); }); }).catch(() => { console.log("app.initialize() failed, page is called outside teams"); });

app is imported using: import { app } from "@microsoft/teams-js";

We now changed the code to the deprecated version: if (!!this.context.sdks.microsoftTeams) {
await this.context.sdks.microsoftTeams.teamsJs.app.initialize().then(async () => { await this.context.sdks.microsoftTeams.teamsJs.app.getContext() .then(appContext => { this.inTeams = true; }); }); } Now the authentication occurs correctly on every single load!

One thing to note is, that we have 2 webparts in our project, the other one still works correctly with the newer version of the initialization.

After lots of feedback from our customers most mobile devices are affected. Most of them fail to authenticate on first load but work, if the app is refreshed. Specific devices like the iPhone 13 Pro won't work at all!

We now have a workaround, but the it can't be a solution, as the use of some objects is deprecated, so analysing the issue is still important. We think that there are thousands and thousands of people affected, so ignoring this issue or viewing it with low priority can't be an option.

We are still available for any input you might need for this.

Thank you very much in advance for your response.