Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Magic Code Required for webchat V4.11.0
See original GitHub issueVersion
4.11.0
Describe the bug
- Team have taken following steps. In order not to have 6 digits when User Sign in AD to talk to BOT and can use it. we follow this link https://blog.botframework.com/2018/09/01/using-webchat-with-azure-bot-services-authentication/ to get rid of the 6 digital verification code (aka magic code).
But on 08 February 2021, some users have access to BOT with Microsoft Edge Version 88.0.705.63 and when logged in to talk to Bot and found that it has 6 digits
- In my test environment, I was asked to copy and paste the magic code. And I noticed the error message with ‘getSessionId’ component.
- Here is the source code about getting session id from the webchat.js source code
Steps to reproduce
I am using the following code to connect to the bot service on azure.
<!DOCTYPE html>
<html lang="en-US">
<head>
<title>Web Chat: Full-featured bundle</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<!--
This CDN points to the latest official release of Web Chat. If you need to test against Web Chat's latest bits, please refer to using Web Chat's latest bits:
https://github.com/microsoft/BotFramework-WebChat#how-to-test-with-web-chats-latest-bits
-->
<script crossorigin="anonymous" src="https://cdn.botframework.com/botframework-webchat/latest/webchat.js"></script>
<style>
html,
body {
height: 100%;
}
body {
margin: 0;
}
#webchat {
height: 100%;
width: 100%;
}
.webchat__upload-button {
display: none !important;
}
</style>
</head>
<body>
<div id="webchat" role="main"></div>
<script>
(
async function () {
// In this demo, we are using Direct Line token from MockBot.
// Your client code must provide either a secret or a token to talk to your bot.
// Tokens are more secure. To learn about the differences between secrets and tokens
// and to understand the risks associated with using secrets, visit https://docs.microsoft.com/en-us/azure/bot-service/rest-api/bot-framework-rest-direct-line-3-0-authentication?view=azure-bot-service-4.0
const userId = 'dl_' + Math.random().toString(36).substr(2, 9);
var myHeaders = new Headers();
myHeaders.append("Authorization", "Bearer " + YOUR_TOKEN);
myHeaders.append("Content-Type", "application/json");
var raw = JSON.stringify({"User":{"Id":userId}});
var requestOptions = {
method: 'POST',
headers: myHeaders,
body: raw,
redirect: 'follow'
};
const response = await fetch("https://directline.botframework.com/v3/directline/tokens/generate", requestOptions)
.then(function(serverPromise){
serverPromise.json()
.then(function(j) {
const token = j.token
window.WebChat.renderWebChat(
{
styleOptions: {
hideUploadButton: true
},
locale: 'zh-Hans',
directLine: window.WebChat.createDirectLine({ token })
},
document.getElementById('webchat')
);
document.querySelector('#webchat > *').focus();
})
.catch(function(e){
console.log(e);
});
})
.catch(function(e){
console.log(e);
});
})().catch(err => console.error(err));
</script>
</body>
</html>
Expected behavior
sign in without using magic code.
Additional context
Because of the issues with the previous approach, Azure Bot Service removed the need for the magic code. Azure Bot Service guarantees that the sign-in process can only be completed in the same browser session as the Web Chat itself. To enable this protection, as a bot developer, you must start Web Chat with a Direct Line token that contains a list of trusted domains that can host the bot’s Web Chat client. Before, you could only obtain this token by passing an undocumented optional parameter to the Direct Line token API. Now, with enhanced authentication options, you can statically specify the trusted domain (origin) list in the Direct Line configuration page.
Some channels such as Microsoft Teams, Direct Line, and WebChat are able to do this without the user noticing. For example, WebChat uses session cookies to ensure that the sign-in flow took place in the same browser as the WebChat conversation. However, for other channels the user is often presented with a 6-digit magic code. This is similar to a built-in multi-factor authentication, as the Bot Framework Token Service will not release the token to the bot unless the user finishes the final authentication, proving that the person who signed-in has access to the chat experience by entering the 6-digit code.
Issue Analytics
- State:
- Created 3 years ago
- Comments:13
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@CharingJC, please verify that ‘Enhanced authentication’ is enabled in the Direct Line channel settings for the bot in Azure. If this is not enabled, which is a key part to bypassing needing a magic code, then the
getsessioniderror is produced. Refer to Step 5 of ‘Enabling Directline’ in Using WebChat with Azure Bot Service’s Authentication. In my quick testing, if I ensure ‘Enhanced authentication’ is enabled, the error disappears.If the issue persists with ‘Enhanced authentication’ enabled, please let me know.
Hello, We have the same problem in our environment. We have enabled directline enhanced authentication, we have added our container page URL to trusted domains, but we receive the magic code. Tested in Chrome ver. 101.0.4951.67 and Edge ver. 101.0.1210.53.
Direct line channel configuration is:
The body of our conversation token is: { “bot”: “…”, “site”: “3ylg_kdPhRQ”, “conv”: “7mvRpRKvVKHLBnRkVkfCVE-fr”, “user”: “dl_anonymous”, “origin”: “http://localhost:4200”, “nbf”: 1653917342, “exp”: 1653920942, “iss”: “https://directline.botframework.com/”, “aud”: “https://directline.botframework.com/” }