ProxySupport

This page is being used to capture the requirements for Platform level proxy support (bug 154100)

CVS Requirements

The CVS/Core and CVS/SSH2 use the proxies provided by the Jsch plug-in to make proxy connections. Currently, there is support for two types of proxies: HTTP and SOCKS5. We would require API that allowed us to do something like this:

ProxyInfo[] infos = ProxyInfo.getProxiesFor(String hostName);
ProxyInfo info = getSupportProxy(infos); // method would look for the HTTP or SOCKS5 proxy
if (info == null) {
    // Attempt a direct connection.
    // If the connection failed and there were proxies specified, let the user know that
    // we only support HTTP and SOCKS4
} else if (info.getType() == ProxyInfo.HTTP) {
   // Use host, port, username and password to create an HTTP proxy using Jsch
} else if (info.getType() == Proxy.SOCKS5) {
   // Use host, port, username and password to create a SOCKS5 proxy using Jsch
}

The API we would require is that ability to retrieve the set of proxies that are available for a particular host. This doesn't imply that we need to support the specification of different proxies for each hist but I think it is good to leave room in the API to support this later.

Update Requirements

Update allows the user to enable an HTTP proxy and specify an address and port that is to be used as the proxy. When set, this information is places in the 'http.proxySet', 'http.proxyHost' and 'http.proxyPort' system properties. Update also sets the default authenticator (Athenticator.setDefault(...)) in order to support interactive authentication (i.e the user is prompted if the update server or proxy require authentication).

WTP Requirements

The WTP proxy preference page currently only sets JVM system properties for http, https, and socks. It does not provide any api to access this information. It assumes that clients will use Java IO( which uses these properties) to create connections. Since, a number of components in WTP use Java IO to open connections, these JVM system properties need to set when the Eclipse UI starts up. This preference page also sets the default authenticator at UI startup time so that the user is prompted for userid and password information. The authenticator also caches user id and password information so that if the same host is accessed again the user does not need to enter this information again.

Discussion

Here are discussions on various aspects of this feature

Access to Proxy info

For CVS to use this feature, the Core plug-in needs to provide access to the defined proxy settings. It also needs the authentication information, if there is any, to be provided with the proxy information since the Jsch proxy does not appear to support an authentication callback. From a CVS standpoint, we need API that looks something like this:

1. a proxy info (or data) object that contains the type, hist, port, username (if required) and password (if required).
2. a method to retrieve the proxy info (or infos) for a particular target host. Clients will need to pick an appropriate proxy to use.

To support this, we would need a preference page that allows the specification of multiple proxy types along with the authentication for each type, if there is any.

Setting System Properties

Both Update and WTP set the Java proxy system properties. For Update, this is done when the core bundle starts. However, WTP does this using the startup hook to ensure that the properties are set when any URL or TCP (in Java 1.5) connections are attempted. In the current implementation, it seems that WTP and Update could easily interfer with each other.

One approach to this is to have the new plug-ins just set these properties for everyone. The advantage of this is that clients of URL and 1.4 and URL and TCP in 1.5 would get the proxy support automatically. However, the main issue is that the settings would need to be put in the properties before any connections were attempted. Possible approaches to solve this would be:

1. specify the options on the command line (not really an option but we do need to consider what happens if somebody does provide them this way)
2. don't specify Lazy-start in the bundle manifest (I'm not sure about this but I'll find out)
3. use the Workbench IStartup hook
4. require any clients that want proxy support to depend on the Core proxy plug-in and call a method indicating that they require the properties to be set.

It seems a bit wierd to force every client the uses Java I/O to have to also make call to the Proxy plug-in to enable JVM properties. However, bundles in the Platform are not typically loaded during startup except extension points or dependencies. I think it will be difficult to get approval to have the proxy bundle start automatically so we may have to settle for point 4, at least for 3.3.

[YMNK]I have questions about setting System Property "socksProxyHost"

• If "socksProxyHost" is enabled, will "http.proxyHost" and "https.proxyHost" be ignored?
• It seems there is not a property like "socksNonProxyHosts".
  Will TCP connections to "localhost" be also proxied? From a CVS standpoint, to support "pserverssh2", it will use ssh2's local port-forwarding and it requires direct accesses to "localhost".

Authenticator

One of the JVM settings that Update and WTP set is the Authenticator. The authenticator is invoked by some Java I/O classes when a username and password is required when making a connection. The Update authenticator simply prompts for the username and password while the WTP authenticator caches authentication iformation.

[MV]Could you describe how the authenticator handles the situation where the remote credentials have changed on the server (i.e. a password has been changed on the server)? I didn't see anything in the Authenticator API that would allow the implementor to distinguish between a first-try and a retry. Also, in the patch, the cache table is written to but never read from.

[PM]In the situation where the credentials have changed or the user enter incorrect credential information Eclipse would need to be restarted to flush this cached data. You are correct that the patch does not read from the cache. This is a bug. The code should have have prefilled the authentication dialog with the cached hostname and password.

[MV]I don't think we want to force a restart, especially if the user has entered the wrong information. We did a simple test and it seems like Java cached the authorization information (i.e. we connected to an http server that required a pasword and made a couple of conenctions. The authenticator was only called once). Do you know of counter examples? I've looked at the javadoc of Authenticator and it is pretty sparse. I think it is dangerous to make too many assumptions so I think it would be best to keep the authenticator simple, at least for 3.3.