从HTML文件中的JavaScript到Bot Framework v4的Microsoft Web Chat控件进行身份验证的正确方法是什么? [英] What is the correct way to authenticate from JavaScript in an HTML file to the Microsoft Web Chat control for Bot Framework v4?

问题描述

我的目标是使用运行此Microsoft Bot Framework v4网络聊天控件的JavaScript创建HTML页面

My goal is to create an HTML page with JavaScript that runs this Microsoft Bot Framework v4 Web Chat Control

https://github.com/Microsoft/BotFramework-WebChat

如有关此StackOverflow问题的评论中所述

As described in the comments for this StackOverflow question

Microsoft Bot Framework图像大小在自适应卡中

我试图在此处遵循示例代码

I tried to follow the sample code here

https://github.com/compulim/BotFramework-MockBot

具体

BotFramework-WebChat-master \ samples \ 01.a.getting-started-full-bundle

BotFramework-WebChat-master\samples\01.a.getting-started-full-bundle

但是无法正常工作.在上面链接的另一个问题中，Microsoft支持人员告诉我要进行另一种身份验证:

but could not get it working. In the other question linked above, I was told by Microsoft support to authenticate another way:

您需要向 https://directline.botframework.com发出POST请求/v3/directline/tokens/generate ，其中授权:标题中为Bearer.另外，您也可以直接使用const token =，

You need to make a POST request to https://directline.botframework.com/v3/directline/tokens/generate with Authorization: Bearer in the header. Alternatively, you can use const token = directly, instead

但是，在上面提到的示例代码中，它说

However, in the sample code noted above, it says

要与您的漫游器对话，您应该使用通过Direct Line机密交换的令牌. 绝对不要将Direct Line机密放在浏览器或客户端应用程序中.

To talk to your bot, you should use the token exchanged using your Direct Line secret. You should never put the Direct Line secret in the browser or client app.

如果上面建议的代码是HTML文件中包含的JavaScript，则加载该页面的任何人都可以从查看源代码"中看到它.

If the code suggested above is JavaScript included in an HTML file, it is visible from View Source by anyone who loads the page.

使用DirectLine机密似乎违反了不公开此机密的规则，我读过此机密可以访问所有对话，而不仅仅是当前对话.

Using the DirectLine secret seems to violate the rule to not expose this secret, which I've read could provide access to all conversations, not only the current one.

如果在纯视图中的JS代码使用DirectLine机密获取令牌，然后使用令牌进行身份验证，则由于公开了DL机密，因此使用令牌似乎无济于事.为什么不只使用DL机密?

If the JS code in plain view uses the DirectLine secret to get a token, then uses the token to authenticate, using the token doesn't seem to accomplish anything, as the DL secret is exposed. Why not just use DL secret?

Microsoft推荐给上面链接的Web聊天控件进行身份验证的最简单方法是什么?

What is the Microsoft-recommended, simplest way to authenticate to the web chat control linked to above?

谢谢！

推荐答案

为什么不仅仅使用DL机密?

Why not just use DL secret?

正如您所说，这将允许访问与该漫游器的所有对话.

As you said, this would allow access to all conversations with the bot.

如果普通视图中的JS代码使用DirectLine机密获取令牌，然后使用令牌进行身份验证，则由于公开了DL机密，因此使用令牌似乎无济于事.

If the JS code in plain view uses the DirectLine secret to get a token, then uses the token to authenticate, using the token doesn't seem to accomplish anything, as the DL secret is exposed.

再次更正.为了隐藏秘密，您需要设置自己的令牌服务器.我们没有关于如何进行此设置的正式，随时可用的示例，但是网络聊天作者创建的该样本应该让您入门.

Correct again. To keep your secret hidden, you'd need to set up your own token server. We don't have an official, ready-to-go sample of how how to set this up, but this sample by the Web Chat author should get you started.

如果您想编写自己的内容，则流程基本上是:

If you want to write your own, the flow would basically be:

1. 让您的WebChat客户端向令牌服务器发送令牌请求
2. 您的令牌服务器可以将机密存储在变量中，只要您不公开代码即可.让您的令牌服务器通过POST请求和标头Authorization: Bearer <YourSecret>
与https://directline.botframework.com/v3/directline/tokens/generate进行联系
3. 将该请求产生的令牌返回给WebChat客户端
   • 您的WebChat客户端现在将拥有令牌，而无需使用密钥，因为它使用了令牌服务器中间件

1. Have your WebChat client send a request for a token to your token server
2. Your token server can store the secret in a variable, so long as you don't make the code public. Have your token server reach out to https://directline.botframework.com/v3/directline/tokens/generate with a POST request and the header, Authorization: Bearer <YourSecret>
3. Return the token that results from that request back to the WebChat client
   • Your WebChat client will now have a token without ever needing to know the secret because it used your token server middleware

Microsoft推荐的最简单的对上面链接的Web聊天控件进行身份验证的方法是什么?

What is the Microsoft-recommended, simplest way to authenticate to the web chat control linked to above?

不幸的是，没有一种方法既是简单的"又是推荐的".最简单的就是直接使用您的秘密.如果您不在乎可以公开用户对话，那很好.但是，推荐的方法是实现自己的令牌服务器.

Unfortunately, there is no method that is both "simple" and "recommended". The simplest is to just use your secret, directly. This is fine if you don't care that user conversations can be exposed. The recommended way, though, is to implement your own token server.

来自此GitHub问题

出于讨论的目的，我们将机密和令牌视为同一件事.如果需要的话，我们稍后会详细介绍.我现在将它们称为秘密/令牌".

For purposes of this discussion, we're going to treat secrets and tokens to be the same thing. We can go into detail on those later if you want. I'll refer to them as "secret/token" for now.

要访问对话，您需要密码/令牌和对话ID.这些值有时粘在一起，有时在单独的变量中.有时它们在URL中，有时它们存储在JavaScript中的内存中.这些类似于存储在用户Cookie中的用户令牌.

To access a conversation, you need the secret/token and a conversation ID. These values are sometimes glued together, and are sometimes in separate variables. Sometimes they're in the URL, and sometimes they're stored in JavaScript in memory. These are similar to a user token, stored in a user's cookie.

在所有情况下，坐在自己计算机上的用户都可以访问这些值.他们可以读取自己的URL，可以读取自己的JavaScript变量状态，还可以读取自己的cookie.

In all cases, these values are accessible to a user sitting at their own computer. They can read their own URLs, they can read their own JavaScript variable state, and they can read their own cookies.

如果他们将任何此类信息发送给其他人，则该人可以冒充他们.如果我的银行通过电子邮件向我发送了密码重置链接，并且我与他人共享该链接，则该人可以重置我的帐户密码并登录到我的帐户.

If they send any of this information to someone else, that person can impersonate them. If my bank emails me a password reset link, and I share that with someone else, that person can reset my account password and log in to my account.

我们的iFrame使用URL传递这些参数，因为在许多情况下，这是足够的安全级别. (您是否曾经访问过网站，是否将URL手动提取到iFrame，发送给其他人，并希望会话保持私密状态?也许不是.)

Our iFrame uses URLs to pass these parameters, as that's an adequate level of security in many cases. (Have you ever visited a website, manually extracted the URL to an iFrame, sent it to someone else, and expected your session to remain private? Probably not.)

如果您想提高安全性，可以跳过iFrame，并在JS或cookie中发送自己的秘密/令牌.您的JS可以提取该内容并将其发送到Web Chat JS对象.一旦Web Chat获得了秘密/令牌，它就专门使用HTTP授权标头将这些值发送到Direct Line服务.

If you want additional security, you can skip the iFrame and send your own secret/token inside JS or a cookie. Your JS can extract that and send it to the Web Chat JS object. Once Web Chat has the secret/token, is exclusively uses HTTP Authorization headers to send those values to the Direct Line service.

因此，公开您的秘密绝不是大交易，本身.但是，它确实允许邪恶的用户冒充其他任何用户.

So, leaving your secret exposed isn't a big deal, per se. However, it does allow a nefarious user to impersonate any other user.

这是 的默认行为，因为Directline需要通过某种方法来确定与之进行身份验证的对象是谁.机密会验证客户端(网络聊天)是否正常.但是，什么可以证明用户是?用户ID?但是，任何用户都可以设置自己的用户ID并假冒其他人.真正确保这一点唯一安全的方法是，在您自己的端上实现一些使用该秘密的事物，以获取Directline令牌，然后将其传递回Web聊天客户端.

This is default behavior because Directline needs some way to figure out who it is authenticated to talk to. The secret verifies that the client (Web Chat) is okay. But what verifies that the user is? A user id? But then any user could set their own user id and impersonate somebody else. The only way to really secure this is to implement something on your own end that uses the secret to get a Directline token, then passes that back to the Web Chat client.

另外，要获取对话数据，有人将需要秘密的和对话ID.找出对话ID的可能性很小.

Also, to get conversation data, somebody would need both the secret and the conversation id. The likelihood of figuring out the conversation id is pretty small.

尽管如此，通常来说，仅当您尝试保留用户数据时，才需要考虑此安全性.如果您的用户每次打开漫游器都会开始新的对话，则只需生成一个唯一的用户ID，就不必担心机密是否已公开.

Generally speaking though, this security is only a concern if you're trying to persist user data. If your users would start a new conversation each time they open the bot, you can just generate a unique user id and not worry if the secret is exposed.

这是一个不错的博客关于在C#和Node中创建客户端控制器(令牌服务器)的文章 以及一些其他安全功能/概念..

Here's a good blog post regarding creating a Client Controller (token server) in C# and Node as well as some additional security features/concepts..

这是另一篇有关其他安全注意事项的博客文章并使用增强的DirectLine身份验证功能

这篇关于从HTML文件中的JavaScript到Bot Framework v4的Microsoft Web Chat控件进行身份验证的正确方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！