Bot Connector - перекрестный разговор API прямой линии?

Я написал небольшой чат на JavaScript для работы с API прямой линии. Чтобы сохранить секрет моего приложения в безопасности, js делает ajax-вызов на мой сервер, где я делаю вызов API на стороне сервера с секретом для создания токена и передачи его обратно в js. Когда пользователь отправляет сообщение, js создает сообщение, чтобы начать разговор (если у меня еще нет идентификатора разговора), затем отправляет сообщение, чтобы получить ответ (ы).

К счастью, когда я начал это, я кое-что погуглил и просмотрел сообщение о включении значения «от» в объект сообщения при публикации или просто начинается с каждого сообщения. Но сейчас все отлично работает, проблем нет.

Потом я заметил то, что казалось странным. Если я открывал браузер и начинал общаться в чате, он начинался с того места, где остановился другой браузер.

Я быстро понял, что это произошло потому, что я жестко закодировал значение «от» в файле js. Но это все еще кажется странным... 2 разных токена, 2 разных идентификатора разговора, 2 разных браузера и 1 разговор. Действительно ли разговоры связаны полем «От» в сообщениях?

Если да, то какой смысл иметь идентификатор разговора? Используют ли они каким-то образом IP- и/или MAC-адрес в сочетании со свойством from?

Я все еще работаю на локальном хосте, поэтому я не тестировал его с двух разных IP-адресов.

Я знаю, что это легко исправить, заставив js генерировать случайное значение для «от», чтобы ограничить разговор временем жизни js, но это все еще кажется странным. Есть ли для этого веская причина или это ошибка?

ОБНОВЛЕНИЕ Ответы см. в вопросе github: https://github.com/Microsoft/BotBuilder/issues/1307#issuecomment-249187807


person Jonny Mohawk    schedule 22.09.2016    source источник


Ответы (1)


Вы должны генерировать случайный идентификатор при загрузке вашего клиента. (Или вы можете использовать существующий идентификатор пользователя в своем приложении, например идентификатор устройства.) Поведение автоматического назначения было источником путаницы и не будет существовать в следующей версии Direct Line. (см. обсуждение GitHub)

person Lars    schedule 29.09.2016
comment
(Добавление ответа, чтобы мы могли отслеживать, решена ли эта проблема) - person Lars; 30.09.2016