From what I can tell there does not exist a way to retrieve a refreshed token from webchat. The approach used to restore a conversation history after a page refresh is to store the token in sessions storage. The problem is that the token is refreshed after 15 minutes to keep the conversation open. This leaves the original token expired.
There needs to be a way to retrieve the refreshed token from webchat in order to maintain state between page refreshes.
Are you using Enhanced Authentication?
Please see the answer to issue "Web chat history not loading"
No, I am not. I need a way to retrieve the updated token from the webchat when the token is refreshed. The refreshed token is needed so that the webchat can be re-instantiated correctly after a page refresh.
I also do not need to use the reconnection api, if I have the refreshed token.
It also seems like it would make sense if there was a sample detailing how the webchat should maintain state between page refreshes. Especially after 15 minutes when the directline token is refreshed.
Hi @scch1002
You are correct. A stored token is not useful for re-connecting to an existing conversation, since it is potentially expired. This is why the reconnection api exists: https://docs.microsoft.com/en-us/azure/bot-service/rest-api/bot-framework-rest-direct-line-3-0-reconnect-to-conversation Please have a look at this, and let us know if it will help you accomplish your goals.
(Also, you are correct that we do not currently have a good story around re-instantiating WebChat state between sessions. This should be something we provide.)
@EricDahlvang, @corinagum, @tdurnford I have taken a look at the reconnection api and Web chat history not loading
That is a solution that can be used. 馃帀
Though the more optimal solution would be to retrieve the live token in the webchat.
I think the problem I had was understanding the documentation for the reconnect api and how that should be integrated with webchat.
There is actually a lot involved in "correctly" restoring WebChat to a previous state. Some things to consider:
The cache of messages provided by the Direct Line connector service are intended to be only for connection reliability, and not a conversation history store. Activities are deleted after 24 hours. So, even if you do reconnect to the existing conversation, this will only enable retrieving messages from the last 24 hours.
Conversation Ids are also only maintained for n number of days after the last activity (i think it is 14, but this is not documented because we reserve the right to change it). Again, the cache on the server itself is only intended to enable connection reliability and reliable delivery ... not intended to be a conversation history.
Security considerations ... user Y should not be able to easily connect to user X's conversation.
Note: https://docs.microsoft.com/en-us/azure/bot-service/rest-api/bot-framework-rest-connector-api-reference?view=azure-bot-service-4.0#send-conversation-history <-- this api is helpful for working around some of these issues, but requires a fair amount of bot code, and we do not currently provide a sample for how this is intended to be used.
I've tried to address these issues with https://github.com/microsoft/BotBuilder-Samples/pull/1706 But, the sample turned into a monster and is probably too large to be usable as a sample.
I'm sorry to say but, we do not currently have a good story around re-instantiating WebChat state between two sessions separated by more than 24 hours of messages. imo, this is work the team should schedule and prioritize as this ootb limitation hinders many potential uses of WebChat and leaves a lot of work to developers if this feature is needed.
My use case does not exceed 4 hours and I am only using the stored messages to maintain the conversation between page refreshes. So, not too extreme on my end.
Ok, good. The reconnect api should work.
Let us know if you run into issues.
Most helpful comment
There is actually a lot involved in "correctly" restoring WebChat to a previous state. Some things to consider:
The cache of messages provided by the Direct Line connector service are intended to be only for connection reliability, and not a conversation history store. Activities are deleted after 24 hours. So, even if you do reconnect to the existing conversation, this will only enable retrieving messages from the last 24 hours.
Conversation Ids are also only maintained for n number of days after the last activity (i think it is 14, but this is not documented because we reserve the right to change it). Again, the cache on the server itself is only intended to enable connection reliability and reliable delivery ... not intended to be a conversation history.
Security considerations ... user Y should not be able to easily connect to user X's conversation.
Note: https://docs.microsoft.com/en-us/azure/bot-service/rest-api/bot-framework-rest-connector-api-reference?view=azure-bot-service-4.0#send-conversation-history <-- this api is helpful for working around some of these issues, but requires a fair amount of bot code, and we do not currently provide a sample for how this is intended to be used.
I've tried to address these issues with https://github.com/microsoft/BotBuilder-Samples/pull/1706 But, the sample turned into a monster and is probably too large to be usable as a sample.
I'm sorry to say but, we do not currently have a good story around re-instantiating WebChat state between two sessions separated by more than 24 hours of messages. imo, this is work the team should schedule and prioritize as this ootb limitation hinders many potential uses of WebChat and leaves a lot of work to developers if this feature is needed.