Unblu, by default, uses a set of entry paths (http request path prefix) as a high-level distinction for origins of requests. In typical on-premises installations these path prefixes are used as a high-level segregation for requests coming from different origins (public internet, intranet or from other systems that belong to the Unblu installation). Based on these path prefixes, Unblu grants different privileges while executing requests.
In typical installations the collaboration server is operated behind a reverse proxy that guarantees requests are restricted according to path prefix and origin of the request.
The system entry path feature is optional and can be disabled by setting com.unblu.identifier.restrictedPathPrefix to be identical to com.unblu.identifier.publicPathPrefix. If enabled, the system entry path feature provides additional security for instance because it generally prevents users from the internet to gain authorization roles that are otherwise reserved for agents.
/unblu path prefix is the part of the server that visitors need to have access to. Typically
/unblu is mapped in a reverse proxy in a way that it can be accessed from within the application that is going to be co-browsed. And typically
/unblu is accessible from the internet.
/co-unblu/` path prefix is the part of the server that agents need to have access to. Typically
/co-unblu is mapped in a reverse proxy in a way that it can only be accessed from the intranet.
/sys-unblu path prefix is the part of the server that MUST only be accessible for other systems (i.e. the filter). By default
/sys-unblu access is disabled. If it is enabled (see com.unblu.systempath.enabled) then during the integration project it must be made sure that access to
/sys-unblu is protected. This can be done by enabling basic authentication
configuration-properties and com.unblu.systempath.basicHTTPAuthenticationPassword or by implementing protection outside of Unblu (i.e., in a reverse proxy).