Certain network topologies and configurations require specific configuration in the server component.
Collaborator may need to connect to other systems, internal or external to the domain. For example, an LDAP server, internal or external SCM systems like GitHub, issue-trackers, URLs provided as part of a review, and so forth. If you are installing Collaborator in an environment where outbound HTTP requests are required to use a proxy, you will need to configure Collaborator to use the proxy.
Proxy settings are configured in the <installation-directory>/ccollab-server.vmoptions file. To enable an HTTP proxy, you will need to add the following lines to that file:
|Tip:||Make sure to replace the
Many proxies are configured to reject connections to internal URL addresses via the proxy, as these connections are supposed to be made directly. For this reason, it is also a good idea to configure internal hosts as non-proxied hosts. Specifically, it is important to configure localhost (including its resolvable name), the bug tracking system, and the version control server as non-proxied hosts. These URL addresses are configured in Collaborator for integration purposes and a connection is made to validate the URL addresses entered in the configuration screens. If the proxy rejects the connections, you may not be able to properly edit those fields. To configure non-proxied hosts, add the following line to the collab-server.vmoptions file:
The format for the value is a list of hostnames delimited by
* for a wildcard.
Some newer firewalls have been known to cause additional problems with HTTP proxying. For instance, some firewalls periodically redirect HTTP requests to a firewall-generated web page requiring the user to log in. These firewalls are specifically designed to limit web access to users – preventing services (such as Collaborator) from accessing web services. Organizations with such firewalls will need to work with their network administrators to exempt Collaborator from this policy or otherwise allow access.