[Tracking] Okta login with widget and CX for transferbot

[ear-dev]

Cameron working on another story for this on the jira board.

https://jira.viasat.com/browse/CUSTSE-6791

[ear-dev]

@Shailesh351 can you please consult with @csmith14 about which API might allow him to set a value in local storage on the client, that the livechat widget can respond to. i.e. we need a mechanism to respond to a payload_action == "display_okta", such that we can open a new webview in the iframe.

[ear-dev]

https://github.com/WideChat/Rocket.Chat.Livechat/tree/develop/src/store

[csmith14]

@Shailesh351 @bhardwajaditya
So we handle all these DFCX 'action' payloads here: https://github.com/widechat/apps.dialogflow/blob/CWS-1299-okta-component/lib/payloadAction.ts#L44

All the current handlers change the room state using an existing apps-engine API (close chat, transfer department), set/update room custom fields, update persistent data, pass message content along from DFCX to the session, or a combination of those.

I had planned to do:
DFCX 'display_okta' payload -> DF App updates room custom field -> Livechat widget gets notified of custom field change -> Livechat widget updates store state -> Okta component is rendered

However, the 'Livechat widget gets notified of custom field change' functionality doesn't seem to exist.

It seems the above flow doesn't adhere to the way the app handles similar events, and I would really like any suggestions.

Thanks

[ear-dev]

@bhardwajaditya @Shailesh351 do you guys have any ideas about the best way for @csmith14 to implement this?

[Shailesh351]

@csmith14 Can't we use the message custom field? We are using it to disable input. We couldn't use the message custom field for typing because of the frequency of typing messages for the session. But in this case, I think it's okay because it will be one time.

[csmith14]

Isn't that a bit of an anti-pattern either way? Is there no apps-engine/livechat API that would be better suited for this type of information exchange?

[ear-dev]

@csmith14 I'm not sure why it's an anit-pattern? It seems to me that passing it in as a message custom field makes sense, because, just like disable input, we're sending a directive to the widget to perform an action and change state. fwiw...

[csmith14]

I'm not claiming that it is an anti-pattern, just asking the question. If that's what we want to do, though, I'll implement it.

It does still leave the question of how to communicate in the opposite direction, though, going from the widget -> DF app

[ear-dev]

It does still leave the question of how to communicate in the opposite direction, though, going from the widget -> DF app

Right.... I was thinking that if we can just go back to the original tab (the one where the CX conversation started) then maybe we can pass a 'silent' message back to DF which will resume the conversation. Maybe if we configure the widget to respond to the response from the Ciao.webApp, after authentication complete, by just closing its current tab, then the original tab will by default come into focus again?

[ear-dev]

@Shailesh351 @bhardwajaditya can you suggest which mechanism @csmith14 can use to send a message from the widget, into an open conversation with the DF.app?

The full workflow is this:

• A conversation with DF starts.
• DF.app sends message to widget with customField indicating it should begin okta authentication flow
• Widget opens a new component/tab and starts the Oath2 flow with "ciao webapp"
• Oauth flow ends with ciao webapp returning json, which contains the auth token, to the component/tab that called the auth flow.
• Widget gets the json from ciao webapp and closes the component/tab, which then re-renders the original tab which contains the DF.app conversation.
• AT THIS POINT we now need to send a message back to the DF.app, into the original conversation, that will include the token and continue the original conversation.
  • The question is: which mechanism can Cameron use at this point to send this "authentication is complete, here's the token" message back into the CX conversation?

thanks.

[bhardwajaditya]

We can use a new authentication successful system message, which can contain the authentication token as a custom field.

Based on the token validation in the DF app we can verify whether to resume or end the conversation there. The room would still need some custom field to indicate that this room can only proceed post authentication

[csmith14]

Summary of my conversation with @bhardwajaditya

We will implement a new API endpoint in RC server to receive roomId, token. This endpoint will be called from the Okta component once data is received back from ciao/iframe.

This endpoint will then update the room custom fields, which will be used to unmount/de-render the Okta component, and will pass the token to the DF app.

[Shailesh351]

@csmith14 @bhardwajaditya Do we get the JSON payload in the widget from the ciao web app? If yes why don't we set room customField from the widget itself instead of using a new API endpoint?

[bhardwajaditya]

@Shailesh351 with room custom fields, we would have to develop an observer sort of mechanism, observers take more resources.

Basically we need something from client side to alert DF bot to proceed with next actions