The SecureFlow Manager (SFM) is an optional part of the Unblu product, separate from the Unblu server itself. It’s designed for site-embedded deployments. These are on-premises installations where the Unblu server and the Unblu-enabled website are both hosted within your company network and exposed to the internet via a web application firewall or other reverse proxy.
The SFM is designed to be integrated into this reverse proxy component. From this position in the network, it can serve two different purposes that enhance the functionality of your Unblu installation:
- Dynamic injection of the Unblu snippet
- Forwarding of protected resources
The SFM can intercept protected resources such as images and CSS as they transit the proxy from the website back-end to the visitor’s browser. It then forwards these resources to your agents' browsers during embedded co-browsing sessions.
Static inclusion, where the snippet is added to the page’s source code.
Dynamic injection, where the back-end code is left unchanged and the snippet is injected by some other mechanism.
The SecureFlow Manager is one mechanism that can be used to perform dynamic injection. An alternative would be to inject the snippet using a tag management system. For more information, refer to Dynamic injection with tag management.
Protected resource forwarding enhances the effectiveness of embedded co-browsing. It helps to ensure that pages your visitors and agent are co-browsing look as similar as possible to all participants.
When a visitor requests a page from your Unblu-enabled website, this is roughly what happens:
Your website’s back-end responds to the initial request by sending the HTML document representing that page.
The visitor’s browser parses the HTML and constructs a Document Object Model (DOM) within the browser.
The DOM doesn’t directly contain all the elements needed to render the page. Resources such as CSS files and images are referenced within the DOM via URL and require an additional request to actually retrieve them.
Once the browser has retrieved all the referenced resources, the browser can finish rendering the page and display the final result.
The visitor’s ability to access the original HTML document and all the subsidiary resources often depends on their having the proper permissions (in an e-banking portal, for example) in the form of a cookie that’s transmitted on each request.
How does embedded co-browsing fit into the picture outlined above?
During an embedded co-browsing session, the Unblu code on the webpage in the visitor’s browser deconstructs the DOM and sends its state information to the Unblu server. Unblu reconstructs the page and serves it to the agent’s browser, giving the agent a view of what the visitor sees.
Because the agent’s browser receives the DOM information through this mechanism and not via a direct request for the webpage, it doesn’t need its own authorization to get the basic structure of the webpage.
Things are different for resources referenced in the DOM. The agent’s browser has to retrieve these resources directly. However, since the agent’s browser doesn’t have the same authorization as the visitor, it won’t be able to retrieve those resources if doing so requires authorization.
This is the problem that the SecureFlow Manager’s protected resource forwarding is designed to address. It does so by intercepting referenced resources as they transit the reverse proxy on their way to the visitor. It then forwards these resources to the Unblu server’s Resource History. Unblu can then use them, in conjunction with the DOM that it already has, to reconstruct the visitor’s view of the webpage for the agent.
The following diagram depicts the flow of data.
Before installing the SecureFlow Manager on your specific reverse proxy product (see links below) it will help to understand some aspects of SFM configuration that apply across all products.
As discussed above, the SecureFlow Manager has two responsibilities: code injection and resource forwarding. The precise way that a specific SFM installation performs these functions is based on a set rules that are defined as part of its configuration.
The configuration of the SFM is actually done in the UI of the Unblu server. The Unblu server then translates these configuration settings into an SFM-specific format and this file is provided to the SFM component.
Specific installation instructions for different reverse proxies are available on the following pages: