Proximity needs access to the Internet to fetch the files requested by users.
In many corporate environments a HTTP Proxy is placed between inner (private) network and outer (public) Internet. Since Proximity uses Commons HttpClient as a default remote repository implementation, all HTTP proxies supported by Commons HttpClient is transitively supported by Proximity.
Proximity offers the maximum of configurability by letting proxy configurations per remotePeer. Thus, for example you can use one remotePeer to access some Maven repository from the "outer world" using HTTP Proxy, and the other to access your colleagues Proximity instance on the same subnet without use of HTTP proxy!
There are general parameters to turn HTTP proxy usage on a Remote Peer. Those parameters are:
When the proxyHost parameter is set, Proximity automatically activates HTTP Proxy usage on a given remote peer. Remember, this is per remotePeer setting!
This completes the HTTP Proxy setup if we have a passwordless HTTP Proxy. For authentication, read further.
For password protected proxy, you have to set further parameters on remotePeer the are required for authentication. Those parameters are:
This way, we are able to access password protected HTTP proxies using HTTP Basic and Digest authentication methods.
For NTLM authentication, you have two more parameters to set on remotePeer:
That's completes the NTLM authentication HTTP proxy authentication setup.
IMPORTANT: Since Proximity relies for HTTP traffic completely on Apache Jakarta Commons HttpClient implementation, the proxy servers supported by HttpClient are automatically supported by Proximity. One of known issue is broken NTLMv2 support for Microsoft ISA Proxy servers. For them, it is advisable to use BASIC or DIGEST authentication, if applicable.