Genesys Cloud - Developer Community!

I posted this on the old developer forum, but can't find it here so I'll do it again.

Was looking to see if anyone had looked at it because I am not getting any joy from support.

This is a bit of an edge case but if a user logs into Genesys Cloud using a browser e.g. Chrome, and that Organisation has domains set as part of the Restrict Genesys Cloud Embedding organisation settings, if this user then at some point in the future, unrelated to their use of Genesys Cloud, uses the same browser to navigate to a web site that uses Genesys Web Messaging, the messenger will not display unless that other web site's domain is listed in the Genesys Cloud organisation settings. This could be any web messaging deployment which is part of any Genesys Cloud install - not the one they originally logged into.

This appears to be because the use of Restrict Genesys Cloud Embedding creates/extends a cookie with values such as: GENESYS-Domain-List and __Secure-GENESYS-Domain-List.

The web messaging code seems to reference these cookies and will not render on the other web site. It is blocked due to CSP (Content Security Policy).

Given that messenger deployments have their own mechanism to restrict domains, I don't see why these cookies should be referenced by web messaging as well.

The response I have been given is that I must list all the relevant web sites in the organisation settings. I.e. any website that may have Web Messenger deployed from anywhere in the world.

@Angelo Cicchitto Does this make sense to you?

In producing more evidence to support who just keep quoting documentation at me, I found I have exaggerated the impact.
It will only affect web messaging deployments, regardless of Organisation, in the same region, not the world e.g. purecloud.com.au.

So, for example, as long as my Genesys users use a bank in another continent, they'll be ok to message them. Otherwise, they will have to call.

------------------------------
Angus Huckle
Procurement
------------------------------

Been watching this with interest and I see you've had no response here at least Angus.  Have you had any luck elsewhere or as you say are you just getting quoted someone's blind reading of the resource centre?

Another support Zoom call. Three Genesys employees on it this time. Showed the issue. Thought they understood it, but then they quoted the same, out of date, Resource Centre page. They say they tested the solution it but when I do exactly as they ask, it doesn't solve the issue.

I've given feedback on the article itself as well - https://help.mypurecloud.com/articles/manage-genesys-cloud-embedding-with-the-genesys-cloud-embedded-clients/ - which tells you to use wildcard e.g. *.salesforce.com, but the UI no longer accepts these.

This is supposedly the problem - wildcards. It's not. It still happens when you have a non-wildcards domain in there such as salesforce.com.

Hi Angus,   I do not know if this might be applicable to your case.  But recently I had a similar experience and support told me that there was a bug in the UI that didn't allow wildcards to be added. But it can be done using the API instead.  And it did work for me at least :)

For example:
PATCH /api/v2/organizations/authentication/settings

{

 "multifactorAuthenticationRequired": false,

 "domainAllowlist": [

  "*.salesforce.com",

  "*.force.com"

 ]
}

Yes. I was aware, thanks.

My issue is that Web Messaging uses this Restrict Genesys Cloud Embedding organisation setting to determine whether to render the web messaging deployment. Because these are stored as cookies on the local machine, it means ANY web messaging deployment in the same region and not just my organisation, is affected.

The most annoying thing is on my support ticket they are repeatedly telling me that wildcards are the problem, are NOT allowed and that the resource centre page is at fault.

Now I am told by the Genesys documentation crowd and by you too that wildcards should be allowed and that the UI is at fault.

I am bemused.

------------------------------
Angus Huckle
Procurement
------------------------------