Resource history

The resource history is a temporary cache of all the resources accessed during embedded co-browsing with an in-context session. It ensures that everything visible in the visitor browser is also visible in the agent browser. The main reason for doing this is to check, validate, and filter resources that are displayed on the agent browser.

Resource history and SecureFlow Manager

The resource history is related to the SecureFlow Manager (SFM). One of the main purposes of the SFM is to capture the resources on a web page sent from your organization’s backend and transfer them to the Collaboration Server. From there, the resources are transferred to the Agent Desk. The page’s Document Object Model (DOM), on the other hand, is captured by the JavaScript in the visitor’s browser and isn’t transferred to the resource history.

When a co-browsing session starts and the visitor’s browser requests images or other resources from your organization’s backend, the SFM is triggered as soon as the response arrives at the proxy. So, while the backend is supplying resources to the visitor’s browser, the SFM is duplicating those resources and uploading them to the Collaboration Server.

The default behavior is that the DOM and image data are stored in temporary memory during a session. They aren’t stored permanently.

Without the SFM in your proxy’s filter chain, agents can’t view session-specific data. The absence of the SFM doesn’t break the session, but content like images generated specifically for that session aren’t visible to the agent. Resources that are only accessible with a valid authentication also aren’t displayed to agents.

The SFM may also be required if the agent’s browser can’t access images or stylesheets from their location on your organization’s network.

Resource types

Typical resource types are binary resources like images, documents (PDF, DOC, and so on) or multimedia content such as audio or video.. Textual resources such as style sheet (CSS) files, and even HTML, can also be classed as resources. There are some exceptions to this rule. The following styles are typically directly contained in a visual and then transformed into resources on the server:

Styles in HTML attributes
Styles in <style> tags

How to enable resource history

To enable the resource history, set com.unblu.visual.resourcehistory.enabled to true.

All the configuration properties related to the resource history can be found in the configuration properties reference.

Behavior with the resource history enabled

When the resource history’s enabled, the agent browser only interacts with the Collaboration Server. It doesn’t request resources from anywhere else.

This provides a high level of security. If the visitor’s browser sends a URI to a resource that hasn’t been added to the resource history, the Collaboration Server has no such resource and returns a 404 not found response, so the agent’s browser can’t resolve that resource.

Browser caching

When the resource history’s enabled, resources are transferred to Unblu, for example, from a reverse proxy where all data to the end user is flying by. Traffic is only monitored by Unblu once a session has started. That means that it may well happen that an end user surfs on the web site, retrieves images and stylesheets and has them stored in their browser cache from that moment on. Once the session starts, the resources no longer fly by the reverse proxy and thus aren’t transferred to Unblu. Unblu detects this and sends the visitor browser commands to re-request such files. However, this behavior may take some time and performance is typically slower with the resource history enabled than without.

Behavior with the resource history disabled

When the resource history’s disabled, resource URIs in visuals are transferred from the visitor’s browser to the agent’s browser unchanged. The resources aren’t transferred to the server or stored. Instead, the agent’s browser requests resources directly from the original backend web server.

The Collaboration Server checks all the URIs requested by the visitor’s browser and only transmits them to the agent’s browser if they point to a resource on the backend web server. The agent’s browser won’t request URIs that point to resources on an unknown web server.

Resource history