Community
Participate
Working Groups
It is critical to have support for proxied/tunelled connections in all components, especially for users who are working from behind corporate firewalls. Here are few common scenarious: -- http/https proxy for http-based protocols -- tunneling over http/https proxy -- tunneling over http/https proxy + ssh -- tunneling over socks I believe most of the low level code is already in jsch library and all above scenarios actually supported by Eclipse cvs plugin.
We would like to know which provider implementations you would like these tunnelling facilities for. e.g. would you like it for the xmpp provider or the ECF 'generic' provider? Since ECF has a provider architecture we can't do it preemptively for all possible providers, but rather we can do it specifically for desired providers. Plus, which of the scenarios are most important for you? We don't have the resources to independently do all of them and so need to be selective and/or recruit others to help out on this. You are right that the ssh/ssh2 libs from jsh are used in the CVS plugin, but unfortunately that plugin does not expose those libraries to other plugins (e.g. ours) so we need to go through using whatever library (jsh or whatever) separately from org.eclipse.team.cvs.ssh2 (or whatever the plugin is).
I believe it would be a bad idea to differentiate between providers and they all should work trough proxy/firewalls. I guess ECF should provide requirements and the common way to configure/retrieve proxy/socks/tunnel settings, so providers could use them directly or trough some adapters. Also, answering your question I am not sure how valuable ECF's proprietory collaboration sever is and it seems that XMPP protocol could be more generic (especially when it will enable the same set of collaboration features). It would be also neat if this protocol allow to communicate with other IDEs such as IDEA or NetBeans.
Hi Eugene (In reply to comment #0) > It is critical to have support for proxied/tunelled connections in all > components, especially for users who are working from behind corporate > firewalls. I agree...but given that we/ECF don't define or even implement the protocol supported by ECF providers, we can't *require* that provider implementations even support proxys and/or tunneling...we can only provide (or point to) support for such things, particularly on the server side. So, for example, consider XMPP. XMPP normally uses port 5222 (open), and port 5223 (ssl). We are using Jive Software's Smack API to implement the ecf xmpp provider. We can/will introduce support in the ECF libs for things like proxy server access and ssh tunneling (perhaps through access to jsch, etc. But we are not yet in the business of implementing servers for XMPP protocol and given the increase in scope doing servers for all providers would imply for the project, we can't in good faith commit to doing that work without some additional support (through donated code, developers, e.g. people to work such a project, an ECF sub-project with committers, etc). So although we share with you the desire to provide proxying and tunneling support for all provider-delivered protocols (and the server side support as well...e.g. proxy servers, http tunnel server, etc), we don't currently have the means to commit to this except in a few limited cases (e.g. ECF 'generic' client/server. If you can/would help us with the means for one or several protocols (e.g. XMPP) I would be most willing to endorse and support such a project. > > Here are few common scenarious: > > -- http/https proxy for http-based protocols > -- tunneling over http/https proxy > -- tunneling over http/https proxy + ssh > -- tunneling over socks > > I believe most of the low level code is already in jsch library and all above > scenarios actually supported by Eclipse cvs plugin. We can/will commit to adding such support in the generic provider (client and server) for socks proxy (already there in JVM), http/https proxy, and ssh tunneling (using jsch and other available tech). And we'll hope that others see this dialog and step up with code contributions, people to join committers to do this and etc...otherwise we can't. Truly, it is an easy thing to create ECF provider implementations (client and server) that do this, and we welcome such efforts.
Added support for proxy in filetransfer API (IRetrieveFileTransferContainerAdapter.setProxy). Implemented on httpclient for http/https. XMPP already has support for proxies. Marking this one fixed. If further proxy support is desired WRT particular APIs and/or implementations then please file additional enhancement requests.
