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?
Thanks
#DigitalChannels------------------------------
Corey Blosser
Wolters Kluwer
------------------------------