We are developing an web application to be displayed inside Genesys. One of the requirement is that SSO must be implemented in this web page. In another word, if user signs in/out of Genesys, we need to sign in/out this web application too.
Using Platform SDK, with client.loginImplicitGrant(), we successfully implemented the sign-in part. However, it doesn't sign out the application if user sign out of Genesys.
Hence, we implemented a web socket connection to listen to the v2.users.${id}.presence event, hoping that we can capture user log-out event and response accordingly. However, while the API can detect when user changes presence to AVAILABLE, BUSY etc., it doesn't detect when user goes OFFLINE. Does anyone know why this may happen?
P.S. I know another way to do it is to invoke Genesys API on a schedule and check whether a 401 error is returned. But I want to avoid such method because it is less predictable.
Keep in mind that Genesys Cloud doesn't have a concept of logged in/logged out. A user can have many auth tokens active at a time, for the same app or for many apps. A user's presence is unrelated to their auth tokens, meaning a user's presence can be set to anything by any app at any time. A user could be actively using an auth token and be in an offline state; there is nothing in the platform preventing this. Auth tokens are not destroyed when an app closes; an app simply stops using its token.
That said, if you're registered for a user's presence events, you'll get events for all of their presence changes. This includes changing to and from an offline presence. If you're missing notifications and it's not for the reason described next and you've validated there was a presence change at those times via analytics presence data, please open a case with Genesys Cloud Care to investigate the missing notifications.
Are you saying you're running a client-side web app in the Genesys UI as a client app and expecting it to receive events after the browser has been closed? It seems unlikely that your app would ever be able to receive the offline event because setting to offline presence is the last thing the app does as it shuts down, or the presence will be set to offline after the fact. You would need to have a service that exists outside the scope of the user's web browser to monitor their presence for offline.
I would recommend using event bridge for your use case because websockets connections are unreliable and do not have guaranteed delivery of messages. Event Bridge does guarantee delivery so you can be sure your app will process every event and not miss any.
You are right that our app is unlikely to receive offline event. Most of the time, our client application is rendered inside an iframe within Genesys. However, since the client application can be rendered on its own, it was deemed as a security issue, and hence the requirements.
But I think I understand your point. Since user performs a loginImplicitGrant() in the client app, even if the user logs out of Genesys, as long as the client app is opened, it will not receive an offline event. May I correct?
So I just wonder: what is the standard SOP to ensure that client application can only be access if and only if a user is currently logged-in in Genesys?
I wouldn't recommend that pattern. You're trying to force two entirely unrelated things to have a dependency where there is none. The Genesys Cloud UI manages its own auth token, and so does your app, entirely separately. A user's other auth sessions are absolutely none of your app's business; OAuth is specifically built for that purpose.
I would recommend focusing on your business requirements and coding your integration so it doesn't matter if the app is in an iframe or a separate window. Anything else is likely to be flaky since you can't control the Genesys app.
If you absolutely must force the two separate apps to act as one, you have to build your app that way. You can use the embeddable client to inject a Genesys Cloud UI into your own web app. Or you can use the API/SDK to build your own frontend app from scratch (a whole lot of work). But to get full control over the app's lifecycle, you have to build it yourself.
To follow up on this specifically, if you're running your own app outside of the Genesys Cloud UI that has registered for the user's presence topic, you will get the presence event for that user when they change to offline. That event is not directly tied to the app's state or the auth token's validity. The presence event could be sent exactly when they close the Genesys Cloud UI, but it could be within several minutes afterwards for two reasons:
If the app itself doesn't get the presence change API request on the wire before it closes, the post-process that happens internally to set users to offline will see the user as gone after a few minutes. That process will change their presence and you'll get the notification at that time. Note that this is a special process tied to the OOTB Genesys Cloud UI. Custom apps cannot/may not use this post-close presence cleanup feature.
Notifications can be delayed by up to 15 minutes before the event is discarded and never sent. The delay is measured in milliseconds during normal operation, but they can be delayed further and eventually discarded and not sent during a platform incident. Event bridge is the only guaranteed way to receive notification events WebSocket message delivery is not guaranteed, event if it was successfully sent; it's like UDP messaging.
This is an example of a potentially flaky solution I mentioned above. Your app could implement presence checks and close itself if the user is set to offline. But having a presence of offline doesn't preclude them from using the Genesys Cloud app, so it's possible for a hiccup in the status management to cause your app to close inappropriately. Or a missed presence message will cause your app to linger open when it should have closed. Maybe this makes the situation better for your business and it's worth implementing, just be aware of the limitations.