I am using the API /api/v2/conversations/{conversationId}/recordings to get all the conversations for the given conversationID. Some of the conversations will be returned in JSONArray, which I can parse very well. Some other converstions are returned as JSONObject, but it does not parse well, I am also seeing a message as "messageWithParams=Recording/RecordingSegment view permission check failed for conversation {conversationId}" Any suggestions why does it returns a JSONObject and what should be doing to capture all recordings?
It sounds like maybe you're getting an error response? Can you share the HTTP response code and the full response body?
responseString "{"message":"ForbiddenException: Recording/RecordingSegment view permission check failed for conversation 97ccf4e3-de73-4978-814c-381b2ef5e822","code":"recording.recording.view.permission.check.failed","status":403,"messageWithParams":"Recording/RecordingSegment view permission check failed for conversation {conversationId}'","messageParams":{"conversationId":"97ccf4e3-de73-4978-814c-381b2ef5e822"},"contextId":"add70d28-da0a-4407-ad9d-ffb561c09113","details":[],"errors":[]}" (id=201)
Hi Somasher,
You are missing permission to retrieve recordings for the role assigned to the OAuth Client. It would help if you ensured the role assigned to OAuth client used by your application had that permission.
Thanks,
John Carnell
Director, Developer Engagement
I am setting accesstoken in Httpclient. I will get response without any errors for other conversations, only on certain conversations, I am getting this error.
This most likely has to do with division access for the permission. However, that's not something we can investigate via the forum as we do not have access to your org's data. If you open a case with Genesys Cloud Care, they can help you identify exactly what division/permission you're missing.
Tim, Yes, you are correct. I updated the roles to include additional divisions to the OAuth, It is working now. I got the clue from John's reply. Thank you, both!
Tim, My Java program expects to download the signed certificate every day. The certificate is valid only for one day? How can I overcome this? I would like to download the certificate and stored it in the keystore for at least a month or couple of months.
I don't know what certificate you're referring to. Can you be more specific? The general Genesys Cloud SSL certs are definitely not reissued every day.
When I run the java program to call Genesys APIs, (starting with https://login.mypurecloud.com/oauth/token), I get the exception as below:
Exception in thread "main" javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Then, I will go to mypurecloud.com to download the certificate and add the CRT to the CACERT keystore to run my program. I have to do once a day.
I am wondering may be the Zscaler installed at my end is causing this restriction?
I don't know what Zscaler is, but this definitely sounds like something in your local environment and is not an expected behavior caused by the Genesys Cloud services. Genesys Cloud uses certs signed by a well-known CA (amazon) that should "normally" already be trusted on your machine. But your IT/security groups may have removed those normally trusted CAs or enacted extra security policies to make you reinstall certs daily for security purposes.
It sounds like your organisation might have a security appliance intercepting HTTPS requests and effectively proxying (and scanning the payload carried over) the connections. To do this the device would have to generate its own certificate (on demand) for the site you are accessing (e.g. mypurecloud.com), which would explain why you see such a short lifetime.
Your best option is to request a security exemption so that the security appliance doesn't intercept connections for this domain (and subdomains). However if that isn't possible there is another way...
The certificates that the security appliance generates should have a chain of trust that ends with a root-CA that has a much longer lifetime (which is hopefully something like 10 years). So if you trust this device, then you can add that root-CA to your trusted roots (e.g. CACERTS keystore) on your system, and then you should be fine for the lifetime of the CA.
Nick.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.