Determining the gadget compatibility is an important activity for planning a VPN-less Finesse deployment.
After deploying the reverse-proxy, all Cisco-provided gadgets (Cisco Finesse, CUIC, and ECE) work seamlessly with their respective servers of Release 12.6 or later.
In some scenarios, depending on the gadget design, custom third-party gadgets require workarounds to enable them to work with
the reverse-proxy deployment. Refer to the following sections to determine if any of your gadgets require workarounds.
Note |
Gadgets that are loaded from servers other than Finesse server, should use exclude-url feature in the gadget XML specification to load the Finesse resources such as Finesse.js. For more information, refer to
the Using Gadget URI Exclude Feature to Refer to Finesse Resources section.
|
Gadget Types and VPN-less Compatibility
Finesse gadgets are classified into the following types based on how they are designed operationally:
-
Gadgets that are self-contained within the desktop without making any additional network requests or is restricted to exclusively
invoke Finesse APIs, APIs on the internet, or both.
-
Gadgets that provide their functionality by communicating with an accompanying server that is deployed in the DMZ and is reachable
directly from the internet and LAN.
Note |
To enable the same desktop layout to be used by both LAN & internet-based clients, server installed in a DMZ should also be
reachable from servers such as Finesse in LAN, and from clients that are running within the LAN.
|
-
Gadgets that need to communicate with an accompanying server deployed in LAN, but uses desktop provided makeRequest API to communicate to the server. The makeRequest API routes all the requests through the Finesse server and does not directly reach the server that is deployed in the LAN.
Note |
These requests succeed in a reverse-proxy deployment only if the requests are made using the hostname and port. The hostname
and the port must be reachable from LAN because the requests are executed by Finesse server which runs on LAN.
|
-
Gadgets that have to communicate directly with any one of the following types of accompanying server:
The last two types of gadgets have to be modified to be used in a reverse-proxy deployment. The steps required to enable these
gadgets to be accessed from internet clients are as follows:
-
Enable VPN-less access for custom gadgets
-
Send hostname and port information to gadgets
-
Use gadget's URI Exclude feature to refer to Finesse resources
Enable VPN-Less Access for Custom Gadgets
Gadgets that communicate directly with accompanying servers that are deployed in LAN must handle the following aspects to
work correctly in a reverse-proxy deployment:
-
Use the right hostname and port for communicating with its accompanying server.
A gadget can find the correct hostname and port corresponding to the server from which the gadget was loaded using the API
gadgets.util.getUrlParameters().up_urlPrefs API provided by the Finesse Javascript API.
To find additional ports or hostnames that are required, data can be passed in as gadget preference such that the additional
host and port information can be sent to the gadget. For more information, refer to the Sending Hostname and Port Information to Gadgets section .
-
Ensure that the communications are forwarded correctly by the reverse-proxy.
After the gadget starts communicating with the correct host and port information, the hostname and port number have to be
forwarded to the server deployed in the LAN by opening the appropriate ports in the DMZ firewall. Also, ensure that the appropriate
ports and rules are added to the reverse-proxy rules to forward the traffic to the correct server in the LAN.
-
Best Practice: If requests to external servers are made using Finesse authentication headers, a common validation is enabled to authenticate
the requests at the proxy. Gadgets that do not use Finesse authentication should plan to implement their own custom authentication
schemes to ensure that the requests are validated at the proxy before sending to the Finesse server.
Send Hostname and Port Information to Gadgets
Gadgets that send host and port information corresponding to a server deployed within the LAN can use the UserPreferences feature supported by Finessse gadgets. This feature allows a configurable, named information to be passed to the gadget.
The information can be referenced within the gadget XML or programmatically by using a Javascript.
For more information on how to use UserPreferences method, refer to https://developer.cisco.com/docs/finesse/#!gadget-preferences.
The UserPreferences created for this purpose should start with the keyword externalServerHostAndPort in its name. This enables Finesse to substitute the host and port provided to be replaced by the corresponding entry from
the proxyMap file. For example:
<UserPref name="externalServerHostAndPort_chat” display_name="Chat_externalServerHostAndPort" default_value="SMHostName:7443"
datatype ="hidden"/>
When accessed from the LAN, the UserPreferences continues to have the default value that is configured in the XML. However, when accessed through the reverse-proxy, the
UserPreferences receives the value from the proxyMap file. For example:
SMHostName:7443=external-proxy-host:4043
When accessed through the reverse-proxy, the gadget receives the port 4043 and host name as external-proxy-host.
Use Gadget URI Exclude Feature to Refer to Finesse Resources
Add the following content within the ModulePrefs tag of the gadget XML to ensure that the resources loaded from Finesse server are excluded from concatenation. This step
is mandatory for gadgets which load their XML from custom servers.
<Optional feature="content-rewrite">
<!-- these files will be directly served by Finesse, not through shindig -->
<Param name="exclude-url">finesse.min.js</Param></Optional>
Feedback