Resource history

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.

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.

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:

An Unblu resource actually consists of two parts:

When the resource history is enabled, the URIs in a visual are transformed to point to the Collaboration Server. They are composed as follows:

The resource-UUID fragment of the URI (the part after the #) is never sent to the Collaboration Server when the agent’s browser requests a resource. It’s only used in the browser.

The reason to have it in the URIs is that it’s appended, for example, to a URI contained in a CSS. Therefore, if the CSS is parsed on the server, the resource UUID can be extracted and the relevant information (especially inbound and outbound references) retrieved and processed. As soon as the CSS arrives at the agent browser, the browser requests the CSS but without the resource UUID.

The fact that it’s actually the blob being retrieved and not the surrounding resource is important. Since blobs are stored in global scope, the agent’s browser only has to retrieve them once. It can then cache them locally. If there are many resources with the same content, then caching is highly effective.

In extreme cases, the agent’s browser can even load a page faster than the visitor’s browser. This can happen if the original webpage contains hundreds of images with differing URIs but always the same data. In the agent browser, all those resources would have the same blob, resulting in the same URI, and thus would be retrieved only once.

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.

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.

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.

Depending on the resource type, a resource is processed before being used, or is used in its original form. A typical processor is the CSS processor.

The main purpose of the CSS processor is to identify resource references within the CSS and replace them with an Unblu resource URI. The Collaboration Server features two kinds of CSS processors:

Resources can have the following states:

Changes to a resource’s state entail changes in its data, that is, the related blob. If the blob changes, the URIs in visuals (and possibly dependent resources such as CSS files) need to be updated. Therefore, a change in state always leads to a cascade of resource updates.

Resources can have incoming (inbound) or outgoing (outbound) references.

For example, a CSS contains a URI to a background image. The referenced image arrives at the server (outbound reference). This triggers a reparsing of the CSS to replace the placeholder URI in the CSS with the new, valid one pointing to the background image in the resource store. (The placeholder exists because the CSS was already parsed initially and all missing resources were collected.) Because the CSS is reparsed, a new entry is generated in the resource store. This triggers the exchange of the previous <link> tag URI with the new one from the reparsed CSS (inbound reference).

If you don’t use the SFM, refer to Managing restricted resources without the SecureFlow Manager.