Unblu 4.1

Filter Usage

1. Purpose

The filter is the component in an unblu integrated system that is responsible for the code injection and for forward webpage resources (images, css) to unblu so that they can be transmitted to the agents browser. Custom filters may in addition be responsible for proxying certain browser requests to the unblu server.

The filter is the link between unblu and the customers website (web or application server). Depending on the deployment scenario, the filter might be part of (or even implement) a reverse proxy, fully integrated in the client's web or application server or integrated into the customers website (client side filter).

2. Filter responsibilities

2.1. Injection

The filters main responsibility is to decide, when to inject which unblu javascript files and to only do this, when a co-browsing session is about to be started or has been started. This is of essential importance, since co-browsing is typically only required for a fraction of website visitors. The filter therefore assures, that the unblu server infrastructure requirements can remain much lower than the website infrastructure requirements. For example, a website delivering 1'000'000 website visits per month may require multiple servers to bear the load, but still only need one unblu server to provide 3'000 unblu co-browsing sessions.

The decision on when to inject what is rule based. The rules are the main configuration element of the filter. They must stay in sync with the unblu server settings. The unblu server provides a json based configuration including rules and injection advise for the filter. The unblu provided filters use this json configuration to decide

2.2. Forward webpage resources

Another filter responsibility is to catch resources as they fly-by and send them to the unblu server in case a co-browsing session is active. This is only required for setups depending on webpage resources delivered by the unblu server. The process of uploading webpage resources is called "add-to-cache" in unblu.

Similar to injections, add-to-cache operations are rule based. Again, the corresponding rules can (and should) be retrieved from the unblu server and must stay in sync with it over time. In contrast to injection, the provided filters do not provide uploading functionality out of the box, though. Instead, they provide means to determine, when uploading is required.

2.3. Proxying

Usually, proxying is the responsibility of the reverse proxy, the unblu filter is running / integrated with. Some setups have no proxies in their existing network topology and introducing one only for the purpose of enabling co-browsing may be too expensive or for other reasons not feasible. In such cases, it may be an option to implement simple proxying yourself.

3. Filter configuration

The filter configuration is json based and can be retrieved from the unblu server using: http://<unbluserver>/sys-unblu/filterBackend/read-configuration .
Replace <unbluserver> with the hostname:port of your unblu server and sys-unblu with your configured systemPathPrefix.

4. Available filters

Filter implementations for a number of well known proxies are provided by and can be requested from unblu in binary or source code form (see below). This includes:

  • native filter (C source code package). Typically used for OEM integrations with proxy providers.
  • apache reverse proxy filter (C source code package). Uses native filter under the hood.
  • F5 BIG-IP iRule (TCL implementation of the filter)

In addition, the following proxies feature unblu filter integrations provided by unblu and / or the proxy distributor: