Почему бы просто не использовать секрет DL?
Как вы сказали, это позволит получить доступ ко всем разговорам с ботом.
Если код JS в простом виде использует секрет DirectLine для получения токена, то использует токен для аутентификации, при этом токен ничего не выполняет, так как секрет DL раскрывается.
Исправьте еще раз. Чтобы сохранить свой секрет в секрете, вам нужно настроить свой собственный токен-сервер. У нас нет официального, готового к использованию примера того, как это настроить, но этот пример от автора веб-чата поможет вам начать.
Если вы хотите написать свой собственный, поток будет в основном:
- Пусть ваш клиент WebChat отправит запрос на токен вашему серверу токенов
- Ваш токен-сервер может хранить секрет в переменной, если вы не делаете код открытым. Пусть ваш токен-сервер достигнет
https://directline.botframework.com/v3/directline/tokens/generate с запросом POST и заголовком Authorization: Bearer <YourSecret>
- Возвращает токен, полученный в результате этого запроса, обратно клиенту WebChat.
- Ваш клиент WebChat теперь будет иметь токен без необходимости знать секрет, потому что он использовал промежуточное ПО вашего токен-сервера
Каков рекомендуемый Microsoft самый простой способ аутентификации в элементе управления веб-чатом, указанном выше?
К сожалению, не существует метода, который был бы "простым" и "рекомендуемым". Самое простое - просто использовать свой секрет напрямую. Это хорошо, если вам все равно, что пользовательские разговоры могут быть раскрыты. Однако рекомендуется использовать собственный токен-сервер.
Дополнительное чтение по раскрытию секрета
С этот выпуск GitHub
Для целей этого обсуждения мы собираемся рассматривать секреты и токены как одно и то же. Мы можем подробно рассказать о них позже, если хотите. Сейчас я буду называть их «секретным / жетоном».
Чтобы получить доступ к беседе, вам потребуется секрет / токен и идентификатор беседы. Эти значения иногда склеиваются, а иногда в отдельных переменных. Иногда они находятся в URL, а иногда они хранятся в JavaScript в памяти. Они аналогичны токену пользователя, хранящемуся в файле cookie пользователя.
Во всех случаях эти значения доступны для пользователя, сидящего за своим компьютером. Они могут читать свои собственные URL-адреса, они могут читать свои собственные переменные состояния JavaScript, и они могут читать свои собственные куки.
Если они отправляют какую-либо эту информацию кому-либо еще, этот человек может выдать себя за них. Если мой банк отправляет мне по электронной почте ссылку для сброса пароля, и я делюсь ею с кем-то еще, этот человек может сбросить пароль моей учетной записи и войти в мою учетную запись.
Наш iFrame использует URL для передачи этих параметров, поскольку во многих случаях это достаточный уровень безопасности. (Вы когда-нибудь посещали веб-сайт, вручную извлекали URL-адрес iFrame, отправляли его кому-то еще и ожидали, что ваш сеанс останется закрытым? Вероятно, нет.)
Если вам нужна дополнительная безопасность, вы можете пропустить iFrame и отправить свой собственный секрет / токен внутри JS или cookie. Ваш JS может извлечь это и отправить его в объект JS Web Chat. Когда веб-чат имеет секретный / токен, он использует исключительно HTTP-заголовки авторизации для отправки этих значений в службу Direct Line.
Таким образом, оставить ваш секрет открытым - это не большая сделка, как таковая . Тем не менее, он позволяет гнусному пользователю выдавать себя за любого другого пользователя.
Это является поведением по умолчанию, потому что Directline требуется некоторый способ выяснить, с кем он аутентифицирован для общения. Секрет подтверждает, что с клиентом (веб-чат) все в порядке. Но что подтверждает, что пользователь? Идентификатор пользователя? Но тогда любой пользователь может установить свой собственный идентификатор пользователя и выдать себя за кого-то другого. Единственный способ по-настоящему обезопасить это - реализовать что-то на своем собственном компьютере, которое использует секрет для получения токена Directline, а затем передает его обратно клиенту веб-чата.
Кроме того, для получения данных разговора кому-то понадобится секретный и идентификатор разговора. Вероятность определения идентификатора разговора довольно мала.
В общем, эта безопасность важна, только если вы пытаетесь сохранить пользовательские данные. Если ваши пользователи будут начинать новый разговор каждый раз, когда они открывают бота, вы можете просто сгенерировать уникальный идентификатор пользователя и не беспокоиться, если секрет будет раскрыт.
Вот хороший пост в блоге о создании Client Controller (токен-сервер) в C # и Node
а также некоторые дополнительные функции / концепции безопасности. .
Вот еще одно сообщение в блоге о дополнительных соображениях безопасности и использовании расширенных функций аутентификации DirectLine