Я использую учебник по аутентификации бот-фреймворка v4 - https://docs.microsoft.com/en-us/azure/bot-service/bot-builder-authentication?view=azure-bot-service-4.0&tabs=csharp. Я настроил соединение OAtuh с помощью приложения AAD в соответствии с инструкциями, пока я тестирую аутентификацию, у меня есть несколько вопросов.
1) Почему до сих пор просит Magic doe? Разве не позаботились об этом после добавления настройки подключения Oauth на портале? 2) Кэширует ли он где-нибудь токен? например Я тестирую, используя нижеприведенный html-файл на моем локальном компьютере. Он отлично работает -> получает токен доступа к моим учетным данным. Но когда я делюсь одним и тем же файлом со своими товарищами по команде, в идеале он должен попросить их войти в систему и использовать свои учетные данные для получения нового токена доступа, но вместо этого он не запрашивает логин и использует мой токен доступа.
Мой код идентичен тому, что есть в https://github.com/Microsoft/BotBuilder-Samples/tree/master/samples/csharp_dotnetcore/18.bot-authentication
<!DOCTYPE html>
<html>
<body>
<div id = "webchat"></div>
<script src = "https://cdn.botframework.com/botframework- `enter code here`webchat/preview/botchat.js"></script>
<script>
window.WebChat.renderWebChat({
directLine: window.WebChat.createDirectLine({ secret: <my seceret>' })
}, document.getElementById('webchat'));
</script>
</body>
</html>





Я размещаю qnabot на wordpress. Использование скрипта PhP для получения токена и сохранения этого токена в переменной (в объекте Window). Веб-чат может забрать токен (приложение Html или React).
Это работало как шарм, пока я не включил Super Cache. Каждый пользователь, запустивший чат-бота на моем веб-сайте, получает новый идентификатор пользователя, но тот же идентификатор разговора, и может присоединиться к разговору. Пришлось остановить чат-бота (опасения gdpr). Это поведение прекратилось, как только я перестал кэшировать на своем веб-сайте. Не лучшее решение (плохо влияет на производительность сайта), но пока нормально.