microsoftTeams.authentication.notifySuccess() causing CancelledByUser error on Windows desktop app

[ghost]

We have a customer who is receiving a CancelledByUser error after taking a code path in our application that calls microsoftTeams.authentication.notifySuccess().

This only happens for them on their Windows desktop client for Teams. The notifySuccess() call works correctly for them in the Teams web client. It also works correctly for me on web, Windows desktop, and Mac desktop.

@microsoft/teams-js version: 1.10.0 Teams for Windows desktop version: 1.4.00.19572 Windows edition: Windows 10 Pro Windows version: 21H1 Windows OS build: 19043.1110

Solutions we've tried without luck:

• Per https://github.com/OfficeDev/microsoft-teams-library-js/issues/349#issuecomment-644857359, https://github.com/OfficeDev/microsoft-teams-library-js/issues/324, our code is waiting for the sdk to initialize via microsoftTeams.initialize(callback) before calling notifySuccess().
• Per https://github.com/OfficeDev/microsoft-teams-library-js/issues/173#issuecomment-456369468, the domain where the sdk is used is the same before/after.
• Our customer cleared their Teams cache on Windows.

Similar issues: https://github.com/OfficeDev/microsoft-teams-library-js/issues/49, https://github.com/OfficeDev/microsoft-teams-library-js/issues/564.

[ghost]

Hi ryannjohnson-range! Thank you for bringing this issue to our attention. We will investigate and if we require further information we will reach out in one business day. Please use this link to escalate if you don't get replies.

Best regards, Teams Platform

[HunaidHanfee-MSFT]

Hey, We are looking into this. We will get back to you soon. Thanks.

[HunaidHanfee-MSFT]

We tried at our end too but didn't faced any issue, can you please share minimal repro code with us? So that we can try with your code once.

[HunaidHanfee-MSFT]

@ryannjohnson-range - Can you check if the customer is getting any error on console? Also please share Teams SDK version.

Here's how you can do that : DevTools for Microsoft Teams tabs

[ghost]

Teams SDK version is 1.10.0.

The customer only sees a source map error in their console:

DevTools failed to load SourceMap: Could not load content for https://teams.microsoft.com/service-worker.js.map: Unknown error

---

For repro code, the auth window is opened successfully with:

microsoftTeams.authentication.authenticate({
  url: window.location.origin + '/auth/start',
  width: 600,
  height: 715,
  successCallback,
  failureCallback
})

And then this is a minimal version of what's run in that popup window

// 1. Opens `/auth/start` when window is created.
// 2. Redirects to different domain.
// 3. Redirects back to original domain at `/auth/end`.
// 4. Runs the following on `/auth/end`:

import * as microsoftTeams from '@microsoft/teams-js';

(async () => {
  await new Promise(resolve => {
    const timeoutId = setTimeout(() => {
      resolve();
      console.warn('Microsoft Teams did not initialize in time');
    }, 1000);

    microsoftTeams.initialize(() => {
      resolve();
      console.info('Microsoft Teams initialized');
      clearTimeout(timeoutId);
    });
  });

  microsoftTeams.authentication.notifySuccess({
    object: 'with',
    jsonable: 'values'
  });
})();

[HunaidHanfee-MSFT]

We have tried the same in our custom app, didn't faced any issue. Can they try to sign-out and login back and check if they are still facing the issue?

[olexu]

One of our customers experiencing the same issue. authentication.notifySuccess() causing CanceledByUser error only in Teams Desktop App. I can't reproduce this issue on my tenant - everything is ok ...

[PodgeHeavin]

I have had the same issue reported to us by numerous customers in production.

We have a published tab app that our cusomters are getting re-directed to our error page even thogh they have completed authtentication and consented correctly and successfully. CancelledByUser error is being returned when the login pop up was in fact not cancelled by the user.

The issue is only prevelant in teams desktop but not the browsers version

OS: Windows 10 Teams version: 1.4.00.22976 (64-bit). SDK version: 1.10.0

Code triggering popup:

    await new Promise<void>((resolve, reject) => {
          MicrosoftTeams.authentication.authenticate({
            url: window.location.origin + '/teams/auth-start',
            width: 600,
            height: 700,
            successCallback: () => resolve(),
            failureCallback: reject
          });
        });

Auth start code:

MicrosoftTeams.getContext((context) => {

    // Generate random state string and store it, so we can verify it in the callback
    const state = uuid();

    localStorage.setItem(Constants.LocalStorageStateKey, JSON.stringify({ state, feature: this.feature}));

    // See https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-implicit
    // for documentation on these query parameters
    const queryParams: URLSearchParams = new URLSearchParams({
      client_id: globalConfig?.clientId,
      response_type: 'id_token token',
      response_mode: 'fragment',
      scope:  globalConfig.authScopes,
      redirect_uri: window.location.origin + '/teams/auth-end',
      nonce: uuid(),
      state: state,
      login_hint: context.loginHint
    });

    const authorizeEndpoint = `https://login.microsoftonline.com/${context.tid}/oauth2/v2.0/authorize?${queryParams.toString()}`;

    // Go to the AzureAD authorization endpoint
    window.location.assign(authorizeEndpoint);
});

Auth End code

    const hash = window.location.hash.replace(/^#/, '');
    const params = new URLSearchParams(hash);

    if (params.has('error')) {

      MicrosoftTeams.authentication.notifyFailure(params.get('error'));

    } else if (params.has('access_token')) {
      const expectedState = this.getStoredState();

      if (expectedState?.state === params.get('state')) {

        if(expectedState.feature === ConsentFeature.files){
        await this.ensureConsentComplete(expectedState.feature);
      }

        MicrosoftTeams.authentication.notifySuccess(JSON.stringify({
          idToken: params.get('id_token'),
          accessToken: params.get('access_token'),
          tokenType: params.get('token_type'),
          expiresIn: params.get('expires_in')
        }));

      } else {
        MicrosoftTeams.authentication.notifyFailure('StateDoesNotMatch');
      }
    } else {
      MicrosoftTeams.authentication.notifyFailure('UnexpectedFailure');
    }
  }

[HunaidHanfee-MSFT]

Thanks for posting. Concerned team is working on it. I will keep you updated.

[HunaidHanfee-MSFT]

We have a bug raised and team is looking into it. I will let you know once it is fixed or got any update on this. Thanks

[PodgeHeavin]

Any update on this. This issue is making our app unusable. We have several user report that they can not use our application because of this issue. This being a production issue, i would expect a better response to the issue

[HunaidHanfee-MSFT]

Team is working on it. I will update you on this. It's hard to find the exact cause of the issue as this is not faced by all.

[PodgeHeavin]

Our app consistantly gets the issue. It might help in debugging Project Central Teams App

[HunaidHanfee-MSFT]

Thanks for sharing we will look into this.

[PodgeHeavin]

Any update on this? This issue is still causing havoc in our production application. We have had to put in multiple workarounds to counteract this issue. None of which really fix the issue. A detailed status of this issue would help.

[cooperhurt]

Any update on this? This issue is still causing havoc in our production application. We have had to put in multiple workarounds to counteract this issue. None of which really fix the issue. A detailed status of this issue would help.

@PodgeHeavin

What work around were you able to do to get this to work? I am also running into this same problem.

[HunaidHanfee-MSFT]

Teams is closely working on it. @PodgeHeavin, @cooperhurt I will update when it get resolved.

[PodgeHeavin]

@HunaidHanfee-MSFT Any sign of this being resolved? what is the status of the issue, can you provide some information? This production issue was raised two months ago. I would expect it to be treated with a little more urgency.

[HunaidHanfee-MSFT]

@PodgeHeavin, Team is working on it and it's in progress. This issue is being treated with high priority. I will update you once it is fixed.

Thanks for understanding.

[cooperhurt]

@PodgeHeavin, Team is working on it and it's in progress. This issue is being treated with high priority. I will update you once it is fixed.

Thanks for understanding.

Been another week or so, was curious if you have any other updates or work arounds to get this to work meanwhile.

[PodgeHeavin]

@cooperhurt Sorry i never got back to you on work around. For the time being we are calling the Graph API to check permissions after we get the cancelled by user error. We can then see the user has in fact consented and move on.

However there is a lag from when the user consents to the graph api returning the updated permissions. So we have put the request to the graph api in a setInterval to run every 5 seconds for a minute trying to get permissions.

It is a pure and utter hack and only work about 50% of the time.

@HunaidHanfee-MSFT We really need a fix for this sooner rather than later. What is causing the delay in producing a fix?

[HunaidHanfee-MSFT]

I understand this feature importance. But internally, team is facing issue with it, as told you its not for everyone, only some are having it that's why it is taking lot of time.

[Aurora12]

We are experiencing this issue with an app that used to work for months. We are using "@microsoft/teams-js": "^1.11.0". Everything is a textbook example and never changed in more than 2 months. If we go through the authentication process (popup client flow), we receive CancelledByUser upon authentication.notifySuccess().

Additionally, we are not receiving a callback for initialize() in the popup (we used to!). This is mentioned here: https://github.com/OfficeDev/microsoft-teams-library-js/issues/680 Not sure this is related of course, but these effects seem to have appeared at the same time.

If this is not the highest priority, I don't know what is!

[Aurora12]

As a temporary sellotape + WD40 workaround we now save the results of the authorisation redirect to local storage in the popup view, then we call notifySuccess() effectively closing the popup, then in the main app's failure callback we read the local storage, and–if the data is there and valid–consider auth flow a success. Oh joy.

[PodgeHeavin]

This is beyond ridiculous. We need a fix for this!!

[cooperhurt]

@PodgeHeavin We tried raising this internally with Microsoft with our Subscriptions and representatives and we get the same answer @HunaidHanfee-MSFT keeps stating. I am not sure about your guys debugging but it appears the actual issues lies in teams desktop app and not this SDK, otherwise I think we could openly contribute to the solution.

[ydogandjiev]

Update: Our engineering teams are still trying to get to the bottom of this issue. As pointed out by @cooperhurt, the problem doesn't lie in the Client SDK but in the Teams Desktop Client or more specifically the custom fork of Electron and Chromium that it is built on top of. When this issue reproes, all messages sent via postMessage between the authentication popup and the Teams main window get dropped making it impossible for the Client SDK to send back the authentication.notifySuccess result or power APIs like getContext. The intermittent nature of this issue and the fact that no one on our Desktop Client team has been able to reproduce the bug has made the investigation very challenging. We have built multiple custom version of the Teams Desktop Client with progressively more and more logging enabled in the postMessage code path within Electron and Chromium. Unfortunately, these logs have so far failed to reveal at what point exactly the messages are getting dropped.

Next Steps: Our engineering teams are continuing to add more logs to Chromium/Electron and in parallel trying to get an internal repro of the issue that we can live debug. As soon as we have identified the cause and have a mitigation plan ready we will update this thread.

What you can do: We know that this issue is impacting your apps and customers and we are very sorry! After this issue has been mitigated we will conduct an extensive post mortem to identify exactly how it slipped through the multiple layers of automated and manual testing we conduct on our product and ensure that it doesn't happen again. In the meantime, if you have identified any clear pattern or a way to consistently reproduce this issue please let us know since it would be extremely helpful to our investigation! Thank you!

Suggested workarounds: This might have been mentioned in some of the replies above but it is possible to work around this issue:

1. In your authentication callback you can write the result of the auth flow into local storage or a cookie and then in your tab's content page read that value to check whether the authentication flow was successful instead of relying on authentication.authenticate API results.
2. If you are calling getContext from the authentication popup then you can move the call into your tab's content page and pass the values you need via QSPs to your authentication flow.

[HunaidHanfee-MSFT]

We have got feedback from a customer that after updating the Teams desktop client to the latest the issue is no longer persists. Could you please try updating the Teams desktop client and check it once?

Please let us know if you are still facing the issue.

Thanks

[cooperhurt]

Curious to hear others thoughts, just tried this on 1.4.00.29478 (MacOS) and still experienced the same issue.

Also just tried this one 1.4.00.33755 with the same issue

@HunaidHanfee-MSFT @PodgeHeavin

[espenjohannessen]

I've just updated to the latest version, 1.4.00.31569 (02.12.2021), and still experience the exact same issue. @HunaidHanfee-MSFT what's the version number that should solve this?

[PodgeHeavin]

@ydogandjiev I appreciate your detailed response to this issue. It is a lot more informative and helpful than "Team is working on it and it's in progress"

The latest version of Microsoft Teams(Version 1.4.00.31569) does not miraculously fix the issue. This is still an on going issue and major problm for our production users.

The issue is visible in our Project Central - Teams app when a user hits "Connect to Project Central" and grants permissions for the first time. Due to the issue the user is prompted to consent for a second time. This is due to the app thinking the user failed consent due to the wrong error being return. I can give further details if you like and walk you through our code and what is happening. I can also provide a test version of our application with source-mapped code for debugging

This issue really needs to be resolved at this stage as it has been going on far too long. @HunaidHanfee-MSFT @ydogandjiev @cooperhurt what is the current status of this issue and what can we do the get this issue resolve in a speedier fashion?

Podge

[cooperhurt]

@PodgeHeavin I dont have an update besides its holding up a new product we are looking to release. Unfortunate...

@HunaidHanfee-MSFT Is there anything we can do to expedite this ticket or get more eyes on it? Looks like Podge has this project available. I can jump on a call and show you ours but it is reproducible every-time on our side.

@ydogandjiev

[grzegorzCieslik95]

Having the same problem.

[HunaidHanfee-MSFT]

We have not got any updates from the internal engineering team. I will post as soon as we have some updates and let you know current status.

Thanks

[cullenjohnson]

As a temporary sellotape + WD40 workaround we now save the results of the authorisation redirect to local storage in the popup view, then we call notifySuccess() effectively closing the popup, then in the main app's failure callback we read the local storage, and–if the data is there and valid–consider auth flow a success. Oh joy.

I also had this problem in desktop AND in the web app when trying to authenticate from the tab config screen. The sellotape + WD40 workaround mentioned above worked for me, but I also find this absolutely ridiculous and frustrating.

[PodgeHeavin]

@HunaidHanfee-MSFT it is nearly 6 months since this issue was raised! Has the internal team not prioritized production bugs? When can we expect a fix for this, this is beyond ridiculous at this stage.

@cooperhurt @HunaidHanfee-MSFT @ydogandjiev We need a FIx and not an update at this stage.

[ChetanSharma-msft]

@PodgeHeavin - We are investigating on this issue and will let you know.

[PodgeHeavin]

I have heard that before:

@HunaidHanfee-MSFT : "Hey, We are looking into this. We will get back to you soon. Thanks." 17-Aug-21

@HunaidHanfee-MSFT : "We have a bug raised and team is looking into it. I will let you know once it is fixed or got any update on this. Thanks" 24-Sep-21

@HunaidHanfee-MSFT : "Team is working on it. I will update you on this. It's hard to find the exact cause of the issue as this is not faced by all." 1-Oct-21

@HunaidHanfee-MSFT : "Teams is closely working on it. @PodgeHeavin, @cooperhurt I will update when it get resolved." 11-Oct-21

@HunaidHanfee-MSFT : "@PodgeHeavin, Team is working on it and it's in progress. This issue is being treated with high priority. I will update you once it is fixed.

Thanks for understanding." 20-Oct-21

@HunaidHanfee-MSFT : "We have not got any updates from the internal engineering team. I will post as soon as we have some updates and let you know current status.

Thanks" 22-Dev-21

@v-chetsh : "@PodgeHeavin - We are investigating on this issue and will let you know." 10-Feb-21

We are never "let know" we have to ask about the issue before we get a response.

I along with many others, still have this production issue. This needs to be taken seriously and resolved. This is a production issue and should be treated as such, making sure it is resolved quickly. How does Microsoft operate, just ignore issues?

[mgwojciech]

Hello, I encountered this issue as well. First of all the "temporary sellotape" will work only if StartAuth and EndAuth pages are stored under same domain as the app itself. This won't be a case for solutions which uses teamsjs to authenticate to 3rd party systems (for example spfx web part consuming serviceNow endpoints) Additionally I also noticed GetOBOToken endpoint doesn't handle well the changes in SP Ext Principal app uri (which needs to happen sooner or later due to changes in app uri validation introduced last year) which means SPFx web parts cannot consume any api even if it was correctly registered as AAD app. In conclusion - and please correct me if I'm wrong here, there is NO reliable way to authenticate to any endpoint in Teams app (of course outside of the web app) Please advise how we can proceed as this is clearly a core element of integration story which MS Teams is the heart of.

[decates]

Just to be clear (I spent a day yesterday trying to investigate the issue before discovering this issue and realising how deep it goes) - as far as I can tell (please correct me if I'm wrong), there is a fundamental issue here that affects the basic function of the JS library for integrating with Teams.

The most basic configuration scenario fails, initialize callback is not called, Save and Cancel/Done buttons don't appear, authentication is not possible, across both web and desktop clients (Mac and Windows). It's reproducible out-of-the-box in about 10 minutes using the MS Teams basic template for a connector following guidance from the MS Learning Module.

Have I got that right?

[mgwojciech]

@decates - this is my understanding as well. I think there is some issue in communication using postMessage method between parent app and hosted frame. I think the issue is it's not affecting all tenants (out of about 100 I could verify this on it was affecting about 10).

[heinrich-ulbricht]

I have a project on the horizon where this issue might affect us as well. Looks like this is going to be "fun".

[Meghana-MSFT]

This issue is triaged and prioritized to be fixed in June.

[barrettlee]

@mgwojciech , where did you find that data about affecting 10 out of 100 tenants? in your experience, would you attribute the cause to a tenant specific issue or is that just a general statistic using tenant as a reference?

[mgwojciech]

@barrettlee my experience. Of course it can be misleading as I have no way to closely verify all of those but based on reported bugs it's about 10%. It's hard to say narrow it down to a specific tenant properties however based on our tests it is tenant specific but have no idea in what way.

[decates]

Thanks @Meghana-MSFT - getting an ETA (even if it's not as soon as anyone would like!) is incredibly helpful to allow us to plan around the issue.

[tianalemesle]

Hello,

Some test I made weirdly indicates that the issue is computer-related :

• our app is available company-wide ;
• someone in our team is experiencing the issue on their computer ;
• I am experiencing the issue on their computer using my Teams account on a different Windows session with a different Teams install ;
• they are not experiencing the issue on my computer using their Teams account on a different Windows session with a different Teams install ;

Moreover, since the issue is happening inside Teams, I think that the cleanest workaround is to make the user perform the OAuth2 process outside Teams then use classic email+password authentication inside Teams.

Thanks

[robfinney]

This issue is triaged and prioritized to be fixed in June.

Good afternoon @Meghana-MSFT can you provide an update around the ETA? Is this still planned for this month? also if it is when can we start seeing it appear in updates?

[TeamsBugHunter]

Hi all, adding to @tianalemesle theory that this is machine specific...

We had this bug reported from a customer using our Teams Tab which is based on the Hello World Tab with SSO sample. I happen to also have this issue but nobody else in the dev team does.

I am using a Thinkpad P14s (Ryzen 7), with latest 1.18 BIOS, Windows 11 latest build, connected to the Lenovo Thunderbolt 3 dock (also latest firmware) with 2 additional 1440p monitors, other team members have varying Thinkpad models (All Ryzen) with varying BIOS versions, and are all running windows 10 still, but all with the same lenovo dock and monitor setup.

What's interesting is if I disconnect from the dock (laptop only) close teams, clear teams cache, and restart I no longer have the bug. If I do the same steps when connected to the dock, I can 100% reproduce this bug.

Also if I succesfully have the login window returned on laptop and then reconnect to the dock WITHOUT clearing the teams cache everything still works.

A colleage on the same laptop model with the last laptop bios and windows 10, also connected to my dock and..... with extended displays and connected to my dock he also reproduced the bug.

We are still waiting for further info from our customer on their full hardware configuration.

Can anyone confirm that a docking station / extended display setup on their specific hardware is causing the issue for them too? At first I thought this is coincidence but like I say 100% reproducable for my setup

My teams version is 1.5.00.14473 (64-bit).

[tiennguyen1293]

I received CancelledByUser upon authentication.notifySuccess() also. And it happening on Window OS, MacOS it's working.

My Microsoft Teams version is 1.5.00.14473 (64bit). it was last updated on 29-Jun-22