I have a use case where Teneo Web Chat should be used on a site where users can sign in to access user specific information via the chatbot. Because the teneo session handling is based on browser cookies persistent between the users sessions of the site, it will show the chat history for any previous user when a new user logs in, but a new session should be started instead and the chat history cleared.
How can I achieve this in the best way? Do I have to remove any previous cookies when signing in to the site (before initializing the bot)? Or should I keep track of the active teneo session in the web server and then call the endsession endpoint when a user change is detected?
Hi, just to clarify, in your use case, are users sharing the same browser/computer? As in, one user visits the site and chats with the bot, then the next user sits down and uses the same computer and browser window? Because in that case, then it is indeed possible that the engine session and chat history persists for different users.
For your information, the chat history displayed in the chat UI and the session with the Teneo engine are treated slightly differently.
Teneo web chat stores the chat history in the session storage (in an object called teneo-web-chat-messages). This object is maintained per tab and maintained as long as a tab is not closed. When a browser or tab is closed, the history shown in the web chat will be deleted. It is possible to delete this object using javascript.
The session that the browser maintains with the Teneo engine however is managed by the browser, and different browsers can treat this in different ways. Some browsers start a new session per tab, some reuse sessions across tabs. Because this session cookie is an httpOnly cookie, it cannot be deleted or changed it using javascript. That can only be done server-side.
What you could consider is to force Teneo web chat to end the session as soon as the user clicks the close chat icon of the Teneo web chat. This will send a request to engine that tells it to end the session. To enable this, in the script that is used to embed the Teneo web chat window in the site, you should set the parameter closeEngineSessionOnExit to yes. You can find an example of the embed script here: https://www.teneo.ai/engine/channels/teneo-web-chat#update-pages.
Yes users may be sharing the same browser and computer in this case.
Is it possible to modify the initialize function for Tene Web Chat to take an additional boolean parameter resetSession that when true will clear the chat history and call the endsession endpoint? This could then be used when a new users signs in.
I donât think relying on the user explicitly closing the chat window to close the session will work in this case. Our idea was also that the âXâ button could be used just to minimize the window while the user is signed in.
Hi Nilst, weâve just pushed out a new release (v2.3.0) of Teneo Web Chat. It now contains a function to reset the chat window programatically. From the readme:
You can programmatically reset the chat window by calling the resetChat() function, for example in an onclick event on your website:
From my testing, the Reset Chat button does clear the chat history and appears to stop the session. Still the message first delivered by the chatbot is the one with the condition %_TIMEOUT which should be the case of a resumed session after a timeout, and not the first welcome message with the condition %_INIT. Only if I clear the cookies to the engine URL do I get the welcome back. Is there something in the session still not reset without clearing the cookies?
What happens is this: when the reset chat button is clicked, a request is sent to engine that will end the session. However, the browser is unaware that the session was ended on the server side. So, when the next user opens the chat window, the browser still thinks the old sessionid should be included in the request.
When that request reaches engine, engine sees the sessionid, but that session no longer exists. Therefore, engine will start a new session and add an annotation %$_TIMEOUT to the request. However, the greeting message flow will only trigger when request contains %$_INIT annotation. So, the greeting message is skipped and as a result the Timeout flow will be triggered.