iOS M365 - Something went wrong [2400] error with webApplicationInfo section

[onmomo]

We learned that iOS M365 app is not able to load a teams app with webApplicationInfo section correctly.

Once we removed the complete section, the error was gone

"webApplicationInfo": {
   "id": "{{APPLICATION_ID}}",
   "resource": "api://{{PUBLIC_HOSTNAME}}/{{APPLICATION_ID}}"
}

Just changing the resource string to something like "resource": "api://{{APPLICATION_ID}}" did not resolve it in the end.

@vikramtha could you escalate this again internally, please?

cross post of (don't know where to report mobile app bugs actually)

• https://learn.microsoft.com/en-us/answers/questions/1614150/ms-teams-integrated-app-on-m365-mobile-(ios)-somet?comment=question

[TrevorJoelHarris]

Hi @onmomo, just wanted to check. Is this something you're running into on the iOS client of Teams specifically, or is it somewhere else?

[onmomo]

Hi @onmomo, just wanted to check. Is this something you're running into on the iOS client of Teams specifically, or is it somewhere else?

Hi @TrevorJoelHarris, this occurs if our teams app is opened inside the iOS M365 native app with said manifest.json version 1.13. This manifest.json works without issues for all the other supported apps (Teams iOS / Android, Outlook iOS / Android, Teams Desktop and Web).

[ChetanSharma-msft]

Hello @onmomo - Could you please confirm whether you have implemented any SSO in your application and let us know what all are the features included? Could you please share the exact repro steps including Manifest and code snippets so that we can try to repro it?

[onmomo]

@ChetanSharma-msft thanks for coming back to me. We implemented external SSO flow. We require the webApplicationInfo section for our teams app backend to communicate with our multi tenant AAD registered App.

This is the most basic manifest.json I was able to come up with. It allows to easily reproduce the error. Please also find the attached packaged app to reproduce it quickly.

error-2400.zip

{
  "$schema": "https://developer.microsoft.com/json-schemas/teams/v1.13/MicrosoftTeams.schema.json",
  "manifestVersion": "1.13",
  "id": "{{APPLICATION_ID}}",
  "version": "{{VERSION}}",
  "packageName": "{{PACKAGE_NAME}}",
  "developer": {
    "name": "acme corp",
    "websiteUrl": "https://www.acme.ai",
    "privacyUrl": "https://www.acme.ai/privacy-policy",
    "termsOfUseUrl": "https://www.acme.ai/terms-of-use"
  },
  "name": {
    "short": "{{NAME_SHORT}}",
    "full": "{{NAME_FULL}}"
  },
  "description": {
    "short": "short",
    "full": "full"
  },
  "icons": {
    "outline": "icon_rest_32.png",
    "color": "icon_color_192.png"
  },
  "accentColor": "#5135C1",
  "publisherDocsUrl": "https://acme.com/docs",
  "staticTabs": [
    {
      "entityId": "helpTab",
      "name": "ACME CORP",
      "contentUrl": "https://en.wikipedia.org/wiki/Acme_Corporation",
      "scopes": [
        "personal"
      ]
    }
  ],
  "webApplicationInfo": {
    "id": "{{APPLICATION_ID}}",
    "resource": "api://{{PUBLIC_HOSTNAME}}/{{APPLICATION_ID}}"
  }
}

I figured out that the contents of webApplicationInfo -> resource attribute is essential to allow reproducing this issue. If I put any url there, the error won't occur. Whereas, if I put the correct url there, the error is triggered. I tested with and without ngrok urls, both cause the issue.

[sakov-ms]

Hi @onmomo, thanks for the detailed repro! We are checking this issue and will provide updates soon.

[AE-MS]

@onmomo I just want to let you know that I'm able to reproduce the problem with the sample app you provided (Thanks!) and I'm working with the M365 app team to make traction on the cause. We haven't forgotten about you!

[AE-MS]

Thanks for your patience while I investigated this issue. The M365 app team is located on the other side of the world than I am so collaboration has taken a little longer than usual due to time zone differences.

I don't have a clear fix for the issue yet, but we've been able to debug that the problem exhibited by the sample app you provided is because of how our system tries to prefetch authentication tokens for apps as a performance improvement for when they actually later request the auth token. In your sample app, one problem is that the contentUrl doesn't match the domain in the resource provided and that seems to be the cause of the issue (apps aren't allowed to request tokens for resources where the domains don't match).

I am still getting to the bottom of this and will report back when I have more details. Thanks!

[AE-MS]

@onmomo Related to what I wrote above, the issue that repros with the sample app you provided is because apps are only allowed to request tokens for domains that their app lives on. E.g., if the URL of the page requesting a token is example.com, the only allowed resource for which it can request a token also has to be on example.com. In the example you provided it's a little different because the "app" (Wikipedia) isn't intentionally requesting a token, but is instead triggering our automatic prefetch logic (we try to retrieve the token on initialization so that it's ready if and when the app does ask for it).

Obviously we have a bug to fix because our prefetch action shouldn't ever trigger UI, even in the case of an error, since it will be confusing to the user and/or developer since it won't be clear what caused it.

However, given the sample manifest you provided, the app could never actually work like that because the content URL domain (wikipedia.org) doesn't match the resource domain (starmind-christian.eu.ngrok.io). In the situation you have actually been trying to enable (i.e. not the sample you provided), do the domains in question match?

[onmomo]

@AE-MS thanks for looking into this. Note, our app does actually not request any tokens or implements SSO with Entra Id . As you suggested, I think the app should not forward this "error" to the user and the implementation should take into account that there might be apps that only require this for sending activity notifications to the user via backend service and not for SSO purposes.

In the real file we have

"id": "{{APPLICATION_ID}}",
"webApplicationInfo": {
    "id": "{{APPLICATION_ID}}",
    "resource": "api://{{PUBLIC_HOSTNAME}}/{{APPLICATION_ID}}"
  },
"validDomains": [
    "{{PUBLIC_HOSTNAME}}"
  ]

We added this section to allow sending notifications to the user via GraphAPI. Without this section we get

Application with AAD App Id '{{APPLICATION_ID}}' is not authorized to generate custom text notifications about '/v1.0/users/73ba1114-08f1-4d3a-8a88-0c2b1ea12345/teamwork/Microsoft.Teams.GraphSvc.sendActivityNotification' to the recipient.

I checked again the docs, and I found the NOTE

Changing this now to an invalid url as suggested, seems to workaround the reported issue. I can no longer reproduce this issue and our GraphAPI sendActivityNotification request still works. It is just a bit dirty IMHO. :-)

"webApplicationInfo": {
    "id": "{{APPLICATION_ID}}",
    "resource": "api://sso-not-implemented"
  }

[AE-MS]

Thanks for the extra details. In response to these details, I've been looking into why the documentation has that seemingly strange note about requiring a dummy string (it's apparently been there for a long time).

Can you help me better understand your scenario so I can ensure we improve the process, docs, or code to better and more clearly support it? When you say that you are sending activity notifications to the user, do you mean that you're using the MS Graph API endpoint like this one? If so, how are you authenticating to the API (e.g., what token are you putting in the Bearer header when making the REST call)? Is it a token you're getting by calling authentication.getAuthToken or something different?

Thanks!

[onmomo]

Thanks for the extra details. In response to these details, I've been looking into why the documentation has that seemingly strange note about requiring a dummy string (it's apparently been there for a long time).

Can you help me better understand your scenario so I can ensure we improve the process, docs, or code to better and more clearly support it? When you say that you are sending activity notifications to the user, do you mean that you're using the MS Graph API endpoint like this one? If so, how are you authenticating to the API (e.g., what token are you putting in the Bearer header when making the REST call)? Is it a token you're getting by calling authentication.getAuthToken or something different?

Thanks!

@AE-MS Yes, we are using MS Graph API POST https://graph.microsoft.com/v1.0/users/${graphUserId}/teamwork/sendActivityNotification. The token used is fetched via "grant_type: 'client_credentials'" from https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token. The provided credentials are configured for the registered app on Azure.

It looks like the dummy url string does the trick, though. The something went wrong [2400] error seems resolved for the M365 iOS app and we can still send activity notifications for the user.

[onmomo]

@ChetanSharma-msft @AE-MS I already provided the feedback. What is the status on this issue, when will this fix you mentioned be implemented for the M365 iOS app?

[sakov-ms]

Hello @onmomo, thank you so much for patience! We have fixed this issue, and it is available in M365 iOS app in versions 2.85.* and above. Please load your app in the latest M365 iOS app and let us know if you face any issues.

[onmomo]

@sakov-ms I just tested with version 2.86.1 and the issue is still there if I don't remove the workaround documented above with the dummy url in the manifest.

[sakov-ms]

Okay. Thanks for getting back on this. We are checking this and will get back with an update.

[sakov-ms]

Hello @onmomo, sorry for the delay but could you share the logs from this error? It will help us debug faster. Thanks!