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?