|This applies to the universal co-browsing component only.|
Unblu supports in-context session migration when co-browsing is initiated. A prerequisite for this capability is that the corresponding setting is in place in the account configuration. In Unblu’s standard session migration procedure, the collaboration server reads the session cookie through a java script activity on the visitor’s browser when the co-browsing session is initiated. The cookie values are passed to the co-browsing session and through a re-load the visitors session state is re-established (i.e., the items already placed in a shopping cart are now also present in the co-browsing sessions.) For session cookies which are secured via an http-only flag, Unblu’s out of the box session migration process does not work as the server cannot read the cookie value through java script. This section describes the necessary additional configuration and instrumentation that needs to be in place so that session migration can also function with http-only secured session cookies.
To support the migration of sessions secured through http-only cookies, a secure and temporary bridge between the web application’s session and the Unblu session needs to be established. This can be achieved with some additional steps implemented in your web application as per the description below. For our example we assume that a backend session (the session that creates the session cookie in your web application) already exists before the user requests a co-browsing session. For example, in our simple sample code the user has already clicked on the button "click to add item to your cart" so that a session cookie is created.
(When we refer to “server” in this example, we are referring to the instrument web application.)
On request of a co-browsing session (user clicks on "Click Here For Live Support"), client sends an AJAX request to the server and creates the bridge.
The server creates a temporary cookie with no http-only flag; this cookie has a short expiration time to maintain security (i.e. 2 minutes).
The cookie value has the encrypted value of the original session cookie.
The server then sends a 200 status code to the client.
As soon as the client gets the success response, it calls the "onSuccess" callback, which creates the dialog to start a session.
The collaboration server always sends a cookie with the response header that carries the name "x-unblu-account-secret`"; the value of that cookie is your account-specific secret key.
On the server side you have a check for session migration; use the bridge you created in step 1 and check for the "x-unblu-account-secret".
Its value is read and decrypted.
The decrypted value is checked against DB/Session-Storage to see whether it is a valid session cookie.
If a-2 is true, then the server checks whether your account secret key matches with the value of the cookie that comes from the server.
If a-2 and a-3 are both true the server creates the original cookie with the value (a-1) of the http-only cookie.
The server deletes the bridge and the temporary cookie.