Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 352072

Summary: RSE attempts to use proxy where it should not
Product: [Tools] Target Management Reporter: Eugene Melekhov <melekhov>
Component: RSEAssignee: Anna Dushistova <anna.dushistova>
Status: RESOLVED FIXED QA Contact: Martin Oberhuber <mober.at+eclipse>
Severity: normal    
Priority: P3 CC: anna.dushistova, ymnk
Version: unspecified   
Target Milestone: 3.4 M7   
Hardware: PC   
OS: All   
Whiteboard:
Attachments:
Description Flags
a link to the preferences in the wizard page
none
Patch that implements the proposed UI none

Description Eugene Melekhov CLA 2011-07-14 08:32:03 EDT
Steps to reproduce:
1. Setup a target connection in RSE and make sure it works.
2. Exit Eclipse and start it again.
3. Go to menu Window/Preferences/General/Network Connections
4. Set Active Provider to 'manual'.
5. Enter a valid IP address and port 8080 for the HTTP proxy.
6. apply & close the windows.
7. Connect to the target in the RSE perspective. That will fail.

Even if you specify the target IP address in the proxy bypass list, it is still
not possible to create a connection.

Analysis: RSE attempts to always use the proxy if one is specified, even for
protocols that should not use a proxy (like ssh) to devices that never should
use a proxy (like targets).

I've been reading the sources (RSE 3.2.2) of the jsch and I see that jsch tries to obtain the proxy for the given host using the Eclipse's IProxyService interface.

1. Currently used jsch version (3.2.2) uses the getProxyDataForHost(host, type)
which does not take into account the protocol (ssh in our case), This function
is depricated in the latest Eclipse (I use Indigo). I believe that it is one of
the root problem.

2. Jsch tries to find proxy for the type SOCKS or else HTTPS. This is also a
bit strange from my point of view. Anyway, in case if there is a proxy for
SOCKS or HTTPS it will be used for ssh, which is not correct actuially.

As a workaround It's possible to clear entries for SOCKS and HTTPS in network
configuration. In such case the proxy won't be used for ssh. It works for me.
Comment 1 Martin Oberhuber CLA 2012-01-04 07:55:48 EST
This sounds like bug 221843, which was resolved as a duplicate of bug 238796 .

I think that the "Proxy bypass" list on the Preferences : General : Network page should work to exclude hosts. I'm not sure whether it can also exclude networks (I think it should, so that might be a valid enhancement request against Platform e.g. using netmask notation like "128.224.199.0/ffffff00" or "128.224.199.0/24).

Beyond that, protocol-specific proxy lists have often been discussed but AFAIK never been implemented; AFAIK a SOCKS proxy is meant to be able and translate ANY socket connection protocol including SSH. So in my understanding, as of today Eclipse Proxy UI is meant to be used for all protocols (which is at least consistent, ant may be expected in many cases). See also bug 221332 comment 1 for some background.

Maybe somebody (org.eclipse.core.net ?) would need to register a special proxy provider for SSH and give it priority over SOCKS
Comment 2 Anna Dushistova CLA 2012-01-04 10:58:14 EST
I tested it and the bypass option now works for hosts, haven't tested networks yet.
Comment 3 Anna Dushistova CLA 2012-01-04 18:57:57 EST
Martin, do you think it would be possible to at least have an option in the new connection wizard to inherit/bypass the proxies? 
I agree about SOCKS, but jcraft also uses HTTPS settings. I think it's incorrect.
Comment 4 Martin Oberhuber CLA 2012-01-05 11:28:24 EST
This is an interesting idea. 

Since we know that jsch uses a configured proxy by default (for SOCKS at least), the new connection wizard could have an option 

   Direct connection (bypass proxies)

When it's enabled, the target IP is automatically added to the proxy exclusion list.

I guess my only concern is about lifecycle of such automatic settings. What if the target IP is changed / deleted ... the proxy exclusion would remain. It may be better to just add a button to the new connection wizard, which brings up the proxy configuration preference page (maybe with the new IP prefilled). Then users know what gets configured and where, rather than doing magic under the hood.

I dont quite understand your comment about HTTPS.
Comment 5 Anna Dushistova CLA 2012-01-06 09:47:39 EST
Created attachment 209133 [details]
a link to the preferences in the wizard page

Martin,
How about something like this?
Comment 6 Anna Dushistova CLA 2012-01-06 09:48:51 EST
Never mind, I read the links you mentioned before and I now take this back.

(In reply to comment #4)
> I dont quite understand your comment about HTTPS.
Comment 7 Martin Oberhuber CLA 2012-01-09 03:50:54 EST
I certainly have no objections to this approach (provided that you can code it with OK dependencies).

Is this kind of integration sufficient for you in terms of usability ? I.e. will users know when they need to navigate into the Proxy Preferences ?
Comment 8 Anna Dushistova CLA 2012-01-24 17:46:56 EST
Created attachment 210019 [details]
Patch that implements the proposed UI

Here is how I want to do it. Martin, do you think it's okay to check this in?
Comment 9 Anna Dushistova CLA 2012-02-06 12:55:42 EST
Also, which properties file should I use to externalize my string?
Comment 10 Anna Dushistova CLA 2012-02-14 14:47:57 EST
I checked in the proposed patch. I don't think there is much else we can do here, so I am resolving it as fixed.