The physical/logical placement of the SecureFlow Manager within the proxy’s filter chain is crucial. The reason for this is that the Collaboration Server needs to process the exact URLs of the resources that are requested by the visitor browser. Often, within a filter chain, that URL, for whatever reason, can be altered on the way to the backend server.
Ideally, the SecureFlow Manager should be as close to the front of the request queue as possible. Many potential difficulties can be easily resolved by placing the SecureFlow Manager within the filter chain in such a way as it receives the data before any other filter has had a chance to make any changes to that data.
The following diagram shows the flows surrounding the SecureFlow Manager.
Note that placing the SecureFlow Manager as close as possible to the visitor browser, within the proxy’s filter chain, is a simple rule of thumb that you can use to offset possible problems. We cannot know what any organization has within its filter chain. And it may even be that, within a complex system, it is difficult to be sure of what is being changed where. Therefore, if you know, for sure, that the incoming requests will arrive at the SecureFlow Manager without any modifications of the URL then that will work. But if you have any doubts at all concerning exactly what is happening within your filter chain, then simply placing the SecureFlow Manager at the appropriate position in the filter chain will offset possible problems arising from the integrity of the request not being perfectly intact.
When a co-browsing session has started, the SecureFlow Manager will pick up the URLs from the request queue and the image and style sheet data from the response queue.
|The proxy must be configured such that all ‘/unblu’ (slash unblu) requests go to the collaboration server.|