Since the initial migration to Genesys Cloud for one of our business units, we are seeing hundreds of web messaging interactions daily with no participant data. Since there is no participant data, per the flow, the interaction immediately disconnects. This issue has been happening prior to the migration of this business unit to Genesys Cloud, when we were testing. We have been working with Genesys Customer Care and unable to determine what is creating these interactions. I'm looking to the community for suggestions on what our dev team may do to help find the cause so they can hopefully eliminate all of these bogus interactions.
The web development team has two messenger deployments (Prod/Non-Prod), each having its own headless messenger configuration. The dev team created their own messenger interface, and that interface is accessible via their support website after a customer authenticates to the site. The deployments are configured to only run on specified domains and only domain included is their support site. There is no issue with customers generating web messages during normal support hours. After support hours, the button to initiate a web message session in unavailable on the support website. The theory is no web message could be created unless it came from their support site domain during support business hours, via an authenticated customer, and that customer manually initiating the web message session.
Both deployments have the same issue but I'm currently focused on the Prod version. The mysterious web messenger interactions are created at all hours, well after the end of support at 7pm Central. It appears the creation of these interactions is constant 24 hours a day. Usually, an interaction is created every 1-3 minutes. Sometimes, I'll see 2 created within the same minute.
The web development teams says they have no indication through their logging that any web message sessions were generated through their website at the time we see them in Genesys Cloud analytics. The idea of a Denial Of Service attack has been suggested because one of the developers was able to use the deployment id through Postman to duplicate the issue. I have no reason to believe that both deployment ids were immediately leaked outside the company for someone to use so I'm a bit skeptical about the idea.
Has anyone seen an issue like this? Any suggestions to help us track down the cause?
Hi @Blosser_Corey If you're not already familiar with the Auto start feature, i would have a look at Configure Messenger - Genesys Cloud Resource Center and customer-join
It's possible these Conversations are getting started from those presence join events? You could attempt to turn them off for your Non-Prod version, and test there possibly.
You can also help validate this theory by GETting the interactionId(s) in question (messaging-apis), and seeing what message(s) are being persisted on them. Which will help you maybe figure out how exactly they started.
I apologize. I'm not following how the Auto Start or customer-join could initiate a web session, when the customer is not given an option to start one. Many of these happen after hours when the web site doesn't provide a live agent chat button. Here is what the customers sees during after support hours and during support hours.
@Blosser_Corey i'm not sure if it's caused by Auto Start or not, yet. The goal is to try to help you identify 1st, what is causing the interactions to start at all. Then we can try to narrow down why/how those are getting invoked (something on your side, or a bug on GC side, etc). If they're beginning from Auto start, then it's apparent that is at least some of the problem. What is your apprehension with following up on this area? This should be easy to corroborate by GETting the conversations in question and seeing what messages are on them, if it's presence join events only, then that's a pretty good path to start to follow. Then turning that setting off to see if that resolves the unwanted Conversations would help you with eventual fix too, likely.
Are all of your interactions getting created from Auto Start, as well as the unwanted ones? Do you even have auto start enabled on your Web Messaging Deployment?
I think the issue with my response is my lack of knowledge regarding the technical details about how the web message deployment code works on a website and the impact of the Auto Start for a headless mode. In my mind, the thought was if no one on the website is pushing the "chat now" button, then a web message would never be created regardless of if the Auto Start option is enabled or not. That made me feel Auto Start was irrelevant.
Since my last post, I had a conversation with our TAM and think I have a better understand of how the snippet code works when using headless mode. If I'm following correctly, it seems as if the snippet code executes regardless of there being an interface for the web message session. Basically, if the page loads the code, it will try to do something.
The new theory is though the support website has a button specific for starting a live web session, the snippet code is still executing through some interaction with the web page. This execution of the snippet code with the Auto Start option enabled causes a web session to be generated with no interface and no participant data so the conversation is immediately disconnected per the inbound message flow. I have not definitely determined the trigger for the generation of the new web message, but based on my updated understanding, it may be due to something simple as a loading of the page or perhaps someone trying to authenticate to the website. There is a thought that in the process of a customer trying to initiate a web session during support hours, there would one of the short unwanted sessions as well as the expected normal web session. If the trigger is due to some basic interaction with the website, that could explain why I see traffic at all hours. It could be due to normal customer traffic on the support website and sometimes people around the world are on the site when everyone is asleep here.
I tested disabling Auto Start for the messenger configuration and saw the issue with the short web message sessions disappear. After enabling Auto Start again, the issue returned. Your thought that Auto Start is related appears to be the case. Given my prior knowledge, I couldn't make the connection about how it could be related.
I'm not completely confident in my understanding of the impact of Auto Start for this issue. If you can confirm my understanding above is correct and provide any additional insight, that would be great. I'm not quite to the point of just turning off Auto Start and moving on. I'd like to understand why and see if part the issue is also due to how the snippet code was implemented in the website. Perhaps there is a better way or best practice that should be followed.
For reference, the two web message deployments this team are both set to Auto Start. My question is, is that even necessary? I feel it wouldn't be necessary with a headless deployment but perhaps it is "it depends" answer.
Hello @Blosser_Corey
This is also happening to our Web Messaging using Headless SDK on our prod. We have a ticket as well for this and since then there is no update on this mysterious session. I hope someone would give light why this is happening.
@IvanDg With your case, does the creation of the extra web message interactions stop after you disable Automatically Start Conversations in your messenger configuration? Hopefully you are able to make progress with your ticket. It was suggested I post in the developer forum and ticket with support stalled. If disabling the Automatically Start Conversations works for your as well, it sounds like we have a workaround.
@Greg_Boston@tim.smith If you have any additional insight on this topic, that would be great. I'm trying to determine if disabling the auto start conversation is the only fix or if there is better way. Perhaps our web development team is not using best practice when implementing code on the website. Since we are new to Genesys Cloud web messaging, I would like to rule that out as a possibility contributing to the issue.
Hello @Blosser_Corey
We didn't disable it as it is a non-negotiable specification to start the messenger without user typing something so we never tried to do it.
Our ticket has been there for 20 days without notable progress and I mentioned in our ticket, same as your reasoning, that it is not triggered from our custom chatbot because our important participant data was not set.
Thanks for bringing this up. We looked into this and determined this is a defect in our Headless mode of Messenger that needs to be corrected.
The problem here is that the conversation JOIN event is automatically sent (AutoStarted) in headless mode after configuring conversation which happens automatically when both Authentication and AutoStart are enabled, which is incorrect. Instead, it should only be sent when your Messenger UI is opened.
So, in order to do this correctly, there are couple of things that needs from both of us here.
On our end, fix the bug in Messenger headless mode to NOT send conversation JOIN event unnecessarily (as soon as Messenger is loaded into the page).
Provide a way for you to let Messenger know when to AutoStart, i.e., via a new MessagingService command that we will provide, so that you can call it when your Messenger UI is opened.
We will start working on fixing this and let you know when it is ready along with needed documentation to handle #2 above. Thanks again for bringing this up.
Hi @Blosser_Corey, fix for this is rolled out. Documentation is in progress. I the meantime, I'm sharing the same details here so you could start correcting the behavior.
Note: This behavior is corrected for the case where both AutoStart and Authentication are enabled.
In your AuthProvider plugin add the following which tells Messenger to only configure the session and not send auto JOIN event.
When you want to AutoStart the conversation, i.e. typically when you open the Messenger, please execute below join conversation command. This will send the JOIN event which then auto starts the conversation.
