You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The difference between the two configurations lies in the resource property:
Configuration 1 includes the botid- prefix in the resource value.
Configuration 2 excludes the botid- prefix.
Why does the microsoftTeams.authentication.getAuthToken() function behave differently for these configurations, as described in GitHub Issue #2196?
Request:
could anybody clarify the difference between these two configurations and explain how the resource value affects authentication behavior. Additionally, it would be helpful to understand the expected behavior for both scenarios and the correct way to configure the webApplicationInfo property to ensure consistent functionality.
The text was updated successfully, but these errors were encountered:
Is there a specific reason why the Teams app development maintains these two formats of URI (why can't those have same ability)?
Will both URI formats offer the same capabilities in the future?
@asith-w - We currently do not have any info if both URI formats will offer the same capabilities in the future. The doc will be updated if there are any updates to this in future. You can also subscribe to RSS feed to get latest Teams platform updates What's new - Teams | Microsoft Docs
Issue:
Below are two configurations of the
webApplicationInfo
property from the Teams app manifest:Configuration 1:
Configuration 2:
Key Question:
The difference between the two configurations lies in the
resource
property:botid-
prefix in theresource
value.botid-
prefix.Why does the
microsoftTeams.authentication.getAuthToken()
function behave differently for these configurations, as described in GitHub Issue #2196?Request:
could anybody clarify the difference between these two configurations and explain how the
resource
value affects authentication behavior. Additionally, it would be helpful to understand the expected behavior for both scenarios and the correct way to configure thewebApplicationInfo
property to ensure consistent functionality.The text was updated successfully, but these errors were encountered: