Community
Participate
Working Groups
There are at least three proxy settings pages in Callisto. We will work with the Eclipse community to make sure that the core capabilities from these pages are made available at the Platform level, as a single settings page that can be consumed by all. [Runtime, Team, Update, UI]
*** Bug 119278 has been marked as a duplicate of this bug. ***
Comments from an RCP perspective: I have seen and voted for the proxy server bug but eclipse should provide support for auto setting proxy values if they have already been set in the underlying window system. Increasingly (in our admittedly windows focussed desktop deployemt) I am telling users, go into IE tools/preferences, navigate to the proxy settings tab, copy down what you see etc. For deploying rcp applications into customers premises proxy settings should just "happen". The preferences should be available to rcp programmers without them being in the midst of a pde related preference screen. Also many of our users have authenticating proxy servers. IE manages to get through these using the current user credentials. Is this possible as I often get users prompted with a proxy server login for the first time when using a Java application. If nothing else there should be a way to capture and cache the password for future requests.
Another point worth considering for platform-wide proxy support is automatic proxy configuration urls. Many enterprises use it, hardly any client app apart from browsers correctly supports this.
Not that I'm out to stretch the scope of this bug too much, but there are a couple additional aspects of Eclipse-wide network management to touch on. Following bug 88017, WTP's "org.eclipse.wst.internet.proxy" plugin contributes a preference page to manage HTTP and HTTPS proxies. It also jams a java.net.Authenticator into the JRE to prompt for and cache (in memory only, not persistently) userids and passwords for Basic Authentication, which may be part of what Phill asked for in his comment 2. We have also been getting requests to improve our support for SSL. As such, here's a very short laundry list of network qualities of service that should ideally be provided under this bug: 1. Configuration of HTTP proxies. 2. Configuration of HTTPS proxies. 3. Configuration of authenticating proxies. 4. Management of Basic Authentication (for proxies and endpoints). 5. SSL server certificate management (eg. inviting user to accept certs and adding them to trust stores). 6. Customization and/or editing of SSL key stores and trust stores. These are all capabilities that are important to users of the Web Services Explorer, which lives or dies by its ability to get, post or otherwise converse with resources on a network, like WSDL documents, UDDI registries and Web services. One other thought: I've been resisting the urge lately to make any further enhancements to WTP's proxy plugin since the platform intends to tackle the issue, however, I can't do this indefinitely. I'm a bit concerned about this RFE's current priority (P4) and lack of target. Can the priority be raised, and can a concrete target for implementating at least some of the items on the list above be set? Thanks much - CB.
The current thinking on this front is: - put the proxy preferences in a low level plug-ins - take the WTP UI and move it into the platform because it is pretty good as it is. We have not started yet and we don't have plans to start soon. I think that given the relatively contained scope of this item, it would be good if people from the community or other IBM teams could step to it. From there we could see if fancier stuffs could be done.
(In reply to comment #5) > The current thinking on this front is: > - put the proxy preferences in a low level plug-ins > - take the WTP UI and move it into the platform because it is pretty good as it > is. I think some part of WTP's UI is confusing. For instance, instead of "use socks" it should have a drop down for proxy types, like it is done for Team / CVS / Proxy Settings. Probably it should also provide an extension point that would allow to contribute custom proxy types (e.g. tunnel over ssh or http).
This was just a proposal. Eugene would you have time to spend on that item?
(In reply to comment #7) > This was just a proposal. Eugene would you have time to spend on that item? You guys would gave to decide what prefs this stuff should bee stored to and what would be the API to access data. Then I can sketch up the UI and wire it all together.
One more item for the wishlist: graceful proxy fallback. Many users (i.e. me) work behind a proxy at work and directly from home/dsl. Install/update already gracefully neglects proxy when not available. It would be nice if this was part of the standard behaviour.
According to bug 157564 it might be interesting to not only consolidate proxy settings, but also provide a common http client by the platform. Makes sense? Behaviour observed in that bug suggests that e.g. proxy fallback is not handled consistently across different http clients.
*** Bug 168509 has been marked as a duplicate of this bug. ***
Are there any concrete plans to address this issue for 3.3? Milestone?
Since Michael has cancelled the bug 168509 as duplicated one( OK, the word proxy is in both ), I would like to append the main statement here, because it fits no issues/need/wishes in both the current bug or dependencies. In some complicated corporate network security landscapes, firewalls, tunnelings it can result in the CVS repositories, using either no proxy or one or even multiple proxy settings in the same eclipse environment. This makes it impossible to access them simultaneously, if some project has to be synchronized with multiple repositories of the different scopes or inconvenient by switching from intra-scope to inter-scope projects and vice versa. A possible solutions ( I would like to mark it as Nr. 7 in the previously published proxy enhansement task list): -7a- General: a script( XML ?) controlled proxy selection as for example by the MS IE, or -7b- Workaround: a proxy enabling checkbox in the CVS repository properties pane
(In reply to comment #13) Once again, Ilia, another and more frequently used option is to allow to specify list of non-proxied hosts.
(In reply to comment #12) > Are there any concrete plans to address this issue for 3.3? Milestone? > I'm also strongly interested in status of this issue. If it isn't included in 3.3 we will have to introduce yet-another-proxy-settings for Corona - bug 164301.
I have an additional wish, why not a "bypass proxy for local addresses" or a similar action would be "use proxy except for address:list..." In my case, the plugin we built uses internal links which we can't access anymore once we specify a proxy in the Install/Update preference page. This overrides the settings in the internet options. thanks
John, Pascal, et al, in response to Pascal's invitation in comment 5, WTP would like to help out. At long last, we have carved out some time to work on moving our "Internet Proxy Settings" preference page and underlying logic into the Eclipse 3.3 platform. Assuming we don't do anything scary, is there room in the remaining Eclipse platform 3.3 schedule to accept a contribution of this sort? Here's a possible approach for folks to chew on or throw heavy objects at... We will start by refactoring org.eclipse.wst.internet.proxy into two new plugins, core and UI. The core (non-UI) plugin will (1) manage network connection preferences + JRE system properties, (2) cache credentials such as basic auth userids and passwords for proxies and endpoints, (3) provide an API for manipulating the preferences, (4) possibly or eventually provide an HTTP client API, and the like. The UI plugin will contain the preference page, basic authentication challenge dialog, and whatever other UI bits we dream up. Some of this work has already been done, just not committed, in bug 113712. As part of this refactoring work we might take the opportunity to fix a couple related bugs from our past, such as bug 113161 and bug 96726. Apart from that, it's a raw port. We'll attach the resulting plugins for the Eclipse platform team to assess. They could be taken as-is or with refinements. They could be kept intact or have their innards removed and folded into existing Eclipse platform plugins. Once committed, components such as Install/Update and Team CVS might be willing and able to replace their proxy controls by a hyperlink to the new Internet Connection Management page or to eliminate their controls entirely. It looks like WTP's Internet Proxy Settings page has at least the same knobs as Install/Update and Team CVS. Last would be to prioritize and start chipping away on the wish list, which I've tried to cull from past comments and related bugs. This is in no particular order. Chime in if I missed stuff: 1. Import proxy settings from browsers like IE and Firefox (comment 2). 2. Import basic authentication credentials from browsers (comment 2). 3. Cache basic authentication credentials (comment 2). 4. Answer Basic Authentication challenges (comment 4). 5. Answer Digest Authentication challenges. 6. Answer NTLM Authentication challenges (bug 132850). 7. Automatic proxy detection (comment 3). 8. HTTP, SSL (HTTPS), SOCKS, FTP, Gopher proxy types (comment 4). 9. Use a proxy type dropdown box for the above (comment 6). 10. Support graceful proxy fallback (comment 9). 11. Provide an HTTP client API, like Apache Commons HTTPClient [1] (comment 10). 12. Multiple proxy settings (comment 13 / bug 168509). 13. Proxy configuration scripts / Ant tasks (comment 13 / bug 168509). 14. Proxy override for local addresses (comment 16). 15. SSL server certificate negotiation. 16. SSL keystore / trust store management. As things get going, we will crack open a page on the Eclipse Wiki to document requirements, track progress, etc. Also, as always, help is most welcome (Eugene, are you still interested?) Left to our own WTP devices we probably won't get thru too many items on the list above in the 3.3 timeframe. That's all for now. Comments? [1] Apache Commons HTTP Client - http://jakarta.apache.org/commons/httpclient/
(In reply to comment #17) Chris, if you will be porting wtp changes, can please also merge in features from Team / CVS / Proxy Settings UI. Specifically - the proxy type http, socks, etc (item 9). That would allow to unify the UI and common settings. I would also suggest to use Jakarta http client directly, maybe providing some common factory for requesting preconfigured httpclient instance. That would help a lot to handle https connection with self-signed certificates, so platform could provide a common trust manager and cert store along with an appropriate UI for confirming untrusted certificates (item 16 in your list) Another thing to look at is actually remove (don't set) system properties for proxy settings like Install/Update Manager does. It may interfere with other applications and generally is a bad idea to communicate global network configuration this way.
(In reply to comment #17) Chris, when are you planning to have a first version of the WTP proxy settings ported to Platform available as an attached patch? Also, here's a few questions I had: - wrt (12) Multiple proxy settings (comment 13 / bug 168509). Does this mean that different proxy settings could be selected depending on the protocol and / or remote host to be contacted? E.g. have a table of host addresses and associated proxy settings? Bug 106586 seems to request this. - when the common proxy settings page has lots of options, some connection providers (e.g. jsch/SSH2) may not be able to deal with all those options. Any ideas to deal with this, or am I just wrong and this is a non-issue? - I understand the proxy settings will be below an "Internet" category provided by the Platform. Since SSH2 / jsch is being used by more and more projects in addition to Team/CVS (e.g. Polarion SVN, Target Management; others want it, e.g. TPTP bug 147117). It seems to make sense to move the Team/CVS/SSH2 settings below the "Internet" category as well and make the Preferences keys public interface in a similar fashion like the Proxy settings. After all, the jsch connection itself is public API and the ssh2 configuration is globally valid for an installation. I filed bug 170883 against Platform/Team to track this for now.
Chris, your general approach sounds good. I.e., start with a straight refactoring of the existing code and get that into the right shape before tackling the wish list.
John, thanks. Would you please hazard a date by which you would like to have a couple of plugins to assess for Eclipse 3.3?
Martin (comment 19), I have not set a date for completing the port. I've just posted a question to John on that subject. That said, I expect the porting effort to take hours/days, not weeks. To your other questions: 1. Yes, this is how I interpretted Ilia's comment 13, reading "scope" to mean a domain, subnet, pattern or any ol' herd of hosts. Both Apache Commons HTTPClient and J2SE 5's beefed up java.net package make this possible, however, I assume the J2SE avenue is off limits since Eclipse 3.3 must remain J2SE 1.4 friendly. 2. I don't think you're wrong. IMHO, the long term goal of the platform "Internet Connection Management" (notice neither "HTTP" nor "Proxy" are in that proposed title) preference page is to act as the single place for users to manage how Eclipse connects to network resources, which implies support for protocols well beyond just HTTP, such as SSH2. In comment 6 Eugene raised the idea of equipping the Connection Management component with an extension point so that new protocols, and the configuration settings particular to them, could be added over time. Since I'm at best a naive user of SSH2, can you elaborate one what sorts of options an SSH2 connection provider could not deal with? 3. I agree it makes sense to move SSH2 settings under the same category, if not onto a single page (per #2 above). Once we complete the basic port, we'll need to prioritize the wish list and figure out how much else can be contributed in the Eclipse 3.3 timeframe and by whom. Thanks - CB.
(In reply to comment #22) > 1. Yes, this is how I interpretted Ilia's comment 13, reading "scope" to mean a > domain, subnet, pattern or any ol' herd of hosts. Both Apache Commons > HTTPClient and J2SE 5's beefed up java.net package make this possible, however, > I assume the J2SE avenue is off limits since Eclipse 3.3 must remain J2SE 1.4 > friendly. I think it would overcomplicate things and we should shoot for the basic scenario - one global proxy for all protocols. BTW, Team/CVS's ssh client is actually capable of tunneling trough HTTP proxy...
(In reply to comment #22) > In comment 6 Eugene raised the > idea of equipping the Connection Management component with an extension point > so that new protocols, and the configuration settings particular to them, could > be added over time. Since I'm at best a naive user of SSH2, can you elaborate > one what sorts of options an SSH2 connection provider could not deal with? I'd suggest to leave connection management to after 3.3. At this moment we mostly need a common UI and API to access the proxy configuration that can be used by other plug-ins. From the UI point of view this configuration page can be modelled after Firefox's proxy configuration dialog, with one improvement - use table for per-protocol proxy configuration and not the hardcoded form (if we'll need per-protocol proxy). At the beginning, options like autodetect and automatic proxy configuration url could be disabled.
Eugene (comment 18), it should be a fairly simple matter to replace WTP's "Use Socks" checkbox by CVS' "Proxy type" dropdown, though I'm starting to lean towards a list of host/port fields by protocol similar to what dialogs from browsers like IE and Firefox do. As in item #11 from my list, incorporating Apache Commons HTTPClient is a good option, but one to approach cautiously because of (1) the legal and versioning headaches that can accompany pulling third party open source - especially API - into the Eclipse platform, and (2) there are some very good improvements in J2SE 5's java.net package, specifically around proxy configuration and connection management. Re. system properties, are you referring to JRE properties like "http.proxyHost", "https.nonProxyHosts", "socksProxyPort", etc.? If so, Apache's HTTPClient and/or J2SE 5's java.net package will be necessary. In J2SE 1.4, any code (Eclipse and Third Party) that opens URL connections via the JDK needs these properties to be set. Are there other alternatives? Thanks - CB.
Eugene (comment 23, comment 24), for Eclipse 3.3, I completely agree we should do the essential minimum. We haven't the time or resource to get fancy. I'm sure most of the wishlist will remain unaddressed in 3.3. One global proxy for all protocols is a fair starting point, and is basically what today's WTP and CVS preference pages can handle, however, we've also both commented on following the browsers' lead which means at least a single setting per protocol (starting with http, https and socks). Switching to this look, minus any extensibility stuff, strikes me as low hanging fruit. How about this: We'll start on the port, crack open a Wiki page to take requirements, priorities, dates, UI mockups, etc. out of this RFE, and mockup a couple UI layouts to chew on. Interested in helping out? Thanks - CB.
(In reply to comment #26) > One global proxy for all protocols is a fair starting point, and is basically > what today's WTP and CVS preference pages can handle, however, we've also both > commented on following the browsers' lead which means at least a single setting > per protocol (starting with http, https and socks). Switching to this look, > minus any extensibility stuff, strikes me as low hanging fruit. Yea, I know. Though I never used per-protocol proxy settings in browser. > How about this: We'll start on the port, crack open a Wiki page to take > requirements, priorities, dates, UI mockups, etc. out of this RFE, and mockup a > couple UI layouts to chew on. Interested in helping out? I'll try, but can't promise anything. :-(
Re comment #21 - I'll try to find that out, but I'm not likely the one who will be working this on the platform side. The only guideline I can give is that after Feb 9 (M5) there will be much more restriction on API changes, and March 23 (M6) is the absolute API freeze. Obviously, the sooner the better.
(In reply to comment #25) > As in item #11 from my list, incorporating Apache Commons HTTPClient is a good > option, but one to approach cautiously because of (1) the legal and versioning > headaches that can accompany pulling third party open source - especially API - > into the Eclipse platform, and (2) there are some very good improvements in J2SE > 5's java.net package, specifically around proxy configuration and connection > management. > Re. system properties, are you referring to JRE properties like > "http.proxyHost", "https.nonProxyHosts", "socksProxyPort", etc.? If so, Apache's > HTTPClient and/or J2SE 5's java.net package will be necessary. In J2SE 1.4, any > code (Eclipse and Third Party) that opens URL connections via the JDK needs > these properties to be set. Are there other alternatives? jsch (included into platform already) has implementation of http and socks proxy and it used by Team/CVS
Eugene (comment 29), are you referring to JCraft's com.jcraft.jsch plugin [1]? Please bear with me as I'm not at all familiar with it, but are you simply pointing out that this library includes an API for managing connections thru HTTP and SOCKS proxies? If so, for protocols beyond SSH-2? What exact role do you think com.jcraft.jsch would play in the context of a general internet connection management page in the Eclipse platform which will entertain clients and protocols well beyond CVS? [1] http://www.jcraft.com/jsch/
(In reply to comment #30) > are you referring to JCraft's com.jcraft.jsch plugin [1]? Yes. That is the one. > Please bear with me > as I'm not at all familiar with it, but are you simply pointing out that this > library includes an API for managing connections thru HTTP and SOCKS proxies? > If so, for protocols beyond SSH-2? What exact role do you think com.jcraft.jsch > would play in the context of a general internet connection management page in > the Eclipse platform which will entertain clients and protocols well beyond > CVS? I am not saying it have to. But jsch could be used to wrap plain sockets into connections proxied trough http proxy and socks. It is probably possible to create connection factory for Jakarta httpclient that would do that transparently (even on JRE 1.4)... Though connection management is probably beyond the scope of this particular enhancement request.
Created attachment 57322 [details] possible sketched ui This is mostly based on FireFox proxy configuration, except that table is used to show manually configured proxies. Also note that user can't add new protocol types.
Created attachment 57323 [details] source code for proxy preference page Don't pay much attention to the variable names. I drew it in the SWT designer...
Eugene, many thanks for this - The layout looks really slick, and the similarity to Firefox is a good thing, IMHO. We'll probably use our non-proxy hosts table from WTP's preference page, and probably not get to those two auto configuration knobs at the bottom. We will also need to decide on how the content of the table changes when the "Use the same..." button is checked.
John, Peter Moogk on my team here looks after the Internet Preferences component in Eclipse WTP, and will be working on the porting effort to the Eclipse platform. Would you please assign this CR to him? Thanks - CB.
(In reply to comment #34) > many thanks for this - The layout looks really slick, and the similarity to > Firefox is a good thing, IMHO. We'll probably use our non-proxy hosts table > from WTP's preference page, and probably not get to those two auto > configuration knobs at the bottom. We will also need to decide on how the > content of the table changes when the "Use the same..." button is checked. I just put all the radio buttons to illustrate how these features can fit into UI later. As of table, personally I think it is easier to manage coma-delimited list then the table UI like one you have in WTP. For "use same" I'd suggest to disable (gray out) entries other then HTTP.
I agree. Comma-separated list is the common methapher across IE and FF.
Things are getting worse unfortunately. As I outlined in bug 150215, there are special problems related with the static setting of java.net.Authenticator.setDefault(Authenticator). In my scenario, I need to give the proxy credentials in advance (since its a on the fly generated one) and the Authenticator, whatever it is, must not be called for one. I now found that up to jre 1.5.0_04 I could circumvent this problem by setting java.net.UrlConnection.setAllowUserInteraction(boolean) to false. With 1.5.0_06 the implementation apparently changed that this setting is ignored and, when the connection specifies a proxy, the Authenticator is queried ALWAYS in advance, before the proxy returns 307 (Proxy Authentication required). The header field for proxy-authorization is ignored and deleted, if the Authenticator is <code>null</code> or returns <code>null</code>. Therefore any general platform implementation must provide a hook to set/reset the static Authenticator temporarily. See my weblog https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/3937 for a possible solution. Otherwise anybody facing the same problem I have, would be forced to set its own Authenticator statically without the possibility of resetting it (since there is no getter for the previous one).
Assigning to Peter as requested.
(In reply to comment #38) Richard, let's not mix things UP. This enhancement request is mostly targeting common place for specifying proxy settings, but then it is up to your own plugin how do you use these settings. I.e. you can use something like Jakarta httpclient that allows to have complete control on http interaction and not using system properties.
(In reply to comment #40) Hi Eugene, if I get it right, at this place it is only dealt with proxy settings maintenance but NO settings in java.net.* will actually be performed? Unfortunately, the problem I mentioned in comment #38 still persists and there where a couple of bugs opened on this issue which have been marked as a duplicate of this one. To put in clear words: the java library design around java.net.URLConnection and java.net.Authenticator is very bad since things are static. There is no way to query the exisiting (application wide) authenticator in order to replace it temporarily. Even worse: If you specify a proxy for your connection the Sun implementation queries the Authenticator for proxy authentication no matter if that is necessary or not and NO matter whether you specified the appropriate header fields in advance. Even worse, what have been specified will be overriden or deleted (if no Authenticator is specified or the Authenticator returns null. To make this situation more worse, Sun has changed the implementation with 1.5.0_06 such that setting HttpURLConnection.setAllowUserInteraction(boolean) will be ignored for the callback. There are a couple of bugs filed with Sun around that issue which all have been rejected or postponed to Dolphin ignorantly. This puts any client of that API in a bad situation. In my environment I am not allowed to use an open source client (unless it comes with Eclipse). We should deal with this situation here. If everybody ends up doing java.net.Authenticator.setDefault(Authenticator) for himself before each call to HttpURLConnection.connect(), this would be a mess. Even worse, in a multithreaded environment, there is no guarantee that somebody else changes the setting during your request.
I also would have times when I could actually provide the authentication for certain realms. Could the Eclipse authenticator define an extension point so that I could register an additional authenticator for certain realms/protocol settings. The Eclipse authenticator could then delegate to me for those requests otherwise attempt it itself. Ideally the extension point should pass me an object eg IRegisterAuthenticator which has add/remove authenticator methods such that I can add and remove authenticators at run time rather than at extension point processing. I won't always know them at startup.
Phill (comment 42) is right on the money. The Internet Connection Management component is not limited to proxy settings. Basic Authentication is in scope. Though it has since been replaced by OSGi's URLStreamHandlerService, Eclipse introduced the "urlHandlers" extension point to bring a measure of extensibility to Java's rigid singleton URLStreamHandlerFactory class so that multiple plugins could peacefully contribute URL scheme handlers. The JRE's singleton Authenticator makes for a similar story. This is not a statement of priority or containment in Eclipse 3.3, but I think it's important that we set -THE- Authenticator for the Eclipse platform, and that we design (carefully) a means for plugins using java.net to participate in Basic Auth negotiation. That said, and as others have pointed out, we are constrained by the JDK's own rules for when it invokes the Authenticator. We've hit issues in WTP as well (bug 160497). No matter what sort of fancy all-singing-all-dancing Authenticator doohicky we might dream up, there will still be times that java.net.URL and friends simply doesn't provide what some tool developers may need. In these cases, third party libraries like Apache HTTPClient, or the Socket API and a sense of adventure, may be necessary. Cheers - CB.
Created attachment 57823 [details] Screen shot 1
Created attachment 57825 [details] Screen shot 2
I've attached two mock ups of the Internet preference page to this defect. I've built on top of the code that Eugene submitted and tried to incorporate some of the comments from others. The first screen shot has the userid and password information located at the bottom of the page. The second incorporates this information into the protocol table itself. Each has its pros and cons. However, I do like the first one better. I added a new entry in the table called ALL. The setting for this entry will be used for all protocols. The check box enables above the table enables/disables this ALL entry. Let me know what you all think of theses screen mock ups. Thanks.
(In reply to comment #46) > The first screen shot has the userid and password information located at the > bottom of the page. The second incorporates this information into the protocol > table itself. Each has its pros and cons. However, I do like the first one > better. I added a new entry in the table called ALL. The setting for this > entry will be used for all protocols. The check box enables above the table > enables/disables this ALL entry. Let me know what you all think of theses > screen mock ups. Thanks. Because credentials can be different between protocols, the first version not going to work. It also seems like it would be better to either show single ALL entry or per-protocol entries based on the state of that checkbox. I still believe that single text area for the non-proxy hosts will work better then table widget. For example, user can easily copy/paste all the non-proxy hosts when configuring new instance. If that list has many entries (more then 3 will be already enough) it will be much more unfiendly to configure it with the table-based UI.
I think the layout 1 looks best as long as the authentication changes with the protocol selected. The exception list is easier to manage as a table for RCP type users. Could the add host button provide an entry box which could accept a single entry or a comma separated list. With regard to the all I think there should be the list as is which is active when the tick box is clear and a separate host/port pair which is active if the box is ticked (no protocol). The use of ALL on activating the tick box would be way to confusing (it confused me).
Created attachment 57854 [details] FireFox proxy page screen shot
Created attachment 57855 [details] Screen shot with Firefix look and feel
(In reply to comment #48) > The exception list is easier to manage as a table for RCP type users. Phill, can you please clarify why do you think so?
(In reply to comment #50) > Created an attachment (id=57855) [details] > Screen shot with Firefix look and feel Peter, the reason that I used table instead of form for different protocol types is that it better scales for new arbitrary protocols and generally more compact then form simulating tabular structure.
There seems to be a number of concerns with the no proxy list and the "use same protocol" check box. Therefore, I had a look at how Firefox gets this information from the user. I have attached a screen shot of this. Using the Firefox look and feel I created a screen mockup of a new Eclipse internet preference page which I have attached as well. The Firefox page doesn't seem to ask for a proxy userid and password. I assume that they relying on the system to prompt the user for this information if a basic authenicating firewall needs to be gone through. If this is the case can we do the same thing as what Firefox does and not request this information on the proxy page? Let me know what you think. Thanks.
Yes I can, many of the users I have are semi pc literate (sales types). If I give them a comma separated, free text box to manage they will mess it up and then they will phone me and i will have to walk through it character by character to find out where they put the stop instead of the comma or whatever unforseeable thing they have managed to dream up this time. Of course it will then take a while to actually drag out of them what the real problem is. When they tell me one of the lines in the table says "intranet.emeadom01" I can fairly easily spot what has gone wrong. It is also one of my main issues with Eclipse in that is exposes developer type abilities to RCP users. Can you imagine exposing the manage features dialog to a sales person. Sorry going off at a tangent and this is not even the platform update bug I am watching. we currently have a swing based app in about 3000 of our channel partners and a lot of them are now using proxy/authenticating proxy systems. This is quite a high runner in support at the moment. This is why auto detection of IE settings is so important as most PC users don't even know what a proxy server is let alone the (mostly microsoft) domain\username format to get through one. For this reason the screen must be ambiguous and pretty bullet proof (hence why All won't work).
(In reply to comment #54) > Yes I can, many of the users I have are semi pc literate (sales types). If I > give them a comma separated, free text box to manage they will mess it up and > then they will phone me and i will have to walk through it character by > character to find out where they put the stop instead of the comma or whatever > unforseeable thing they have managed to dream up this time. I am not convinced that it would buy you anything. They may as well mistype host names. So, it would be less hassle for them to copy and them paste that list from some documentation you provide to them. Though I do agree that it is important to support automatic proxy detection and even proposed some UI around that.
(In reply to comment #53) > The Firefox page doesn't seem > to ask for a proxy userid and password. I assume that they relying on the > system to prompt the user for this information if a basic authenicating > firewall needs to be gone through. If this is the case can we do the same > thing as what Firefox does and not request this information on the proxy page? It is been requested that in some cases it is needed to know auth info in advance, before requesting proxy.
Created attachment 57894 [details] Repository depended proxy Is the idea of the repository depended proxy dead ? ( see #13 )
(In reply to comment #57) > Is the idea of the repository depended proxy dead ? ( see #13 ) You would be able to achieve the same result using non-proxy hosts settings.
(In reply to comment #58) Unfortunately not. Imagine you have to communicate for some reason with repositories in the network areas A, B, C and D. You are positioned in the network area E. From your position you can reach the E-repositories proxyless and other areas only via different proxy servers/ports proxy-E-A:8080, proxy-E-B:9080, proxy-E-C:9090 and via a tunnel to D ( proxyless ) respectively. With non-proxy hosts ability I could reach only E, D and one of the A, B, C
Created attachment 57897 [details] Multi-proxy example from http://en.wikipedia.org/wiki/Proxy_auto-config A reason for multi-proxying can be bandwidth considerations
(In reply to comment #60) Ilia, the example you showed still has just a single proxy server. (In reply to comment #59) I would kill the local network admin for such multiproxy setup... Though I can see that nothing is ideal. However, personally I don't think the preference page UI in question of this request should deal with settings for arbitrary repositories, but perhaps it could allow to reuse the same UI and provide an unified API for storing these preferences.
I've just completed the first drop of the source code for this feature. It will be attached momentarily. In this drop I've ported over a lot of the WTP code as well as made a number of enhancements. Here is a list of some of the things that have been done. 1) Split WTP code into two plugins. One for non-UI code and one for UI code. 2) Rewritten core code so that hostnames, ports, non proxy hosts, and authentication information can be specified per protocol. However, the current UI implementation only allows the user to specify one non proxy host list and one set of authentication information. This one set of information is passed to all protocols. 3) Rewritten core code, so that it will be much easier to add additional protocols. Note: I have not added any extension points to add new protocols. I think more discussion is warranted on what the api for this extension point should be. In the mean time the current code is in good shape to move towards pluging in new protocols. 4) Enhanced the UI so that it looks more like the Firefox proxy settings. 5) The UI is coded to display an arbitrary number of protocols, which are retrieved from the non-ui code. Since, the current number of protocols is small(ie. HTTP, HTTPS, SOCKS) the current implementation of using Labels and Text fields works fine. If in the future the number of protocols does grow quite large, the UI can be easily rewritten to use a Table. 6) The table displaying non proxy hosts has been updated so that when adding or editing new hosts a comma delimited string can be used. In fact the delimiter can now be either a space, comma, or a vertical bar. This will hopefully address the concerns about cutting and pasting that were raised earlier. My intent with this first drop is get something functional into the Eclipse space as soon as possible for developers to try out. I'm sure that there will be a lot more discussion and changes to this code before the Eclipse 3.3 code freeze date. In the next week or so I'll be focusing on the following three development items: 1) Providing an extension point api for adding new protocols. Please, chime in if you have some ideas on this. 2) Providing an extension point so that extenders can hook into the Authenticator without having to replace the current Authenticator singleton. 3) The current Authenticator caches userid and password information for a particular host so that the user is only prompted once for this information. However, if the user enters incorrect information this information is cached. The Authenticator will then always send this incorrect information to its target without the user having a chance to correct it. Currently, the only way around this problem is to shutdown Eclipse to clear the cache. There are a number of ways to resolve this problem, but I'd be interested in getting some feedback from you all about solutions. Thanks.
Created attachment 58137 [details] Screen shot of Internet UI for source code drop 1
Created attachment 58140 [details] Initial source code drop of the Internet preferences page.
(In reply to comment #62) > 2) Rewritten core code so that hostnames, ports, non proxy hosts, and > authentication information can be specified per protocol. However, the current > UI implementation only allows the user to specify one non proxy host list and > one set of authentication information. This one set of information is passed > to all protocols. It seems like shown UI does not reflect the fact that non-proxy and auth info are specified per protocol. It would make sense to use master-detail idiom for that. > 3) Rewritten core code, so that it will be much easier to add additional > protocols. Note: I have not added any extension points to add new protocols. > I think more discussion is warranted on what the api for this extension point > should be. In the mean time the current code is in good shape to move towards > pluging in new protocols. Also, shown UI also don't imply that new protocols can be added. I believe that table would serve better for such purpose. > 4) Enhanced the UI so that it looks more like the Firefox proxy settings. Can you please clarify why does it have to look like Firefox proxy settings? Besides, if Firefox look is preferred, why don't we have text field for entering non-proxy hosts? :-) My issue with table is that I can't copy its content in case if I need to share these settings with someone else. > 5) The UI is coded to display an arbitrary number of protocols, which are > retrieved from the non-ui code. Since, the current number of protocols is > small(ie. HTTP, HTTPS, SOCKS) the current implementation of using Labels and > Text fields works fine. If in the future the number of protocols does grow > quite large, the UI can be easily rewritten to use a Table. I think it is better to prepare for scaling from the beginning. Also note that this form should leave space for other configuration options, such as automatic proxy detection and using browser settings. By the way, do we really need to have a separate proxy for https protocol? > My intent with this first drop is get something functional into the Eclipse > space as soon as possible for developers to try out. I'm sure that there will > be a lot more discussion and changes to this code before the Eclipse 3.3 code > freeze date. Can you please create some code examples how new proxy configuration retrieval API will be used by the plugins? Perhaps it could go to some wiki page somewhere. > In the next week or so I'll be focusing on the following three > development items: > > 1) Providing an extension point api for adding new protocols. Please, chime in > if you have some ideas on this. > 2) Providing an extension point so that extenders can hook into the > Authenticator without having to replace the current Authenticator singleton. > 3) The current Authenticator caches userid and password information for a > particular host so that the user is only prompted once for this information. > However, if the user enters incorrect information this information is cached. > The Authenticator will then always send this incorrect information to its > target without the user having a chance to correct it. Currently, the only way > around this problem is to shutdown Eclipse to clear the cache. There are a > number of ways to resolve this problem, but I'd be interested in getting some > feedback from you all about solutions. I've created an enhancement request for the common UI for managing saved identities. See bug 171714 at https://bugs.eclipse.org/bugs/show_bug.cgi?id=171714 Unfortunately it require enhancement in the Platform auth api. See bug 171806 https://bugs.eclipse.org/bugs/show_bug.cgi?id=171806
(In reply to comment #65) >>It seems like shown UI does not reflect the fact that non-proxy and auth info >>are specified per protocol. It would make sense to use master-detail idiom for >>that. I agree. The UI does not reflect this. However, is this a big deficiency. Both IE and Firefox don't allow setting non-proxy and auth info per protocol. I agree completely that this should be a wish list item. I just don't think it is something that should be high on the priority list. >>Also, shown UI also don't imply that new protocols can be added. I believe that >>table would serve better for such purpose. Adding new protocols is a separate issue from how they are rendered in the UI. If you have a look at the source code for the UI you will see that the protocols are added dynamically. If a new protocol was added to the core not a single line of UI code would need to changed. >>Can you please clarify why does it have to look like Firefox proxy settings? The main reason for going with the a Firefox look is just user familiarity. Hopefully, if a user has configured these settings in either IE or Firefox the UI will look familiar to them. Note: the IE protocol settings UI is very similar to the Firefox UI. Both of these UIs use Text fields to gather this information. If there is a compelling reason to render this information differently I'm certainly open to suggestions. >>My issue with table is that I can't copy its content in case if I need to share >>these settings with someone else. The current implementation of the code does allow sharing of these setting. Simply select all the hostnames in the table and click edit. A dialog will pop up with a comma delimited list of all the hostnames. This text can then be shared to whoever you want. >>I think it is better to prepare for scaling from the beginning. >>Also note that this form should leave space for other configuration options, >>such as automatic proxy detection and using browser settings. If we do decide to have automatic proxy detection and user browser settings I don't think it will be a problem to have these radio buttons added to the UI. The main issue for these enhancements is priority and time. These two items will entail a fair bit of development work, which I don't think we have the time for right now, unless some kind soul out there would like to contribute the code for them? >>By the way, do we really need to have a separate proxy for https protocol? Firefox and IE both allow these protocols to be configured separately so I assume so. >>Can you please create some code examples how new proxy configuration retrieval >>API will be used by the plugins? Perhaps it could go to some wiki page >>somewhere. In the current code drop I didn't intent to expose the api that the core internet and the internet UI use to communicate. In fact I put this code in internal packages and didn't export them for external use. That being said I'm not opposed to having some kind of api being exposed. Its just that when it comes to exposing apis I think we need to take a very cautious approach, since we will have to live with this api for a very long time. >>I've created an enhancement request for the common UI for managing saved >>identities. See bug 171714 at >>https://bugs.eclipse.org/bugs/show_bug.cgi?id=171714 >>Unfortunately it require enhancement in the Platform auth api. See bug 171806 >>https://bugs.eclipse.org/bugs/show_bug.cgi?id=171806 Woo hoo, these enhancement requests look great. Thanks for letting me know about them! If these requests are implemented the Authenticator wont need to cache this information any more. Cool.
John, now that the first source code has been dropped what is the next step? Will the Eclipse team review it and commit it to CVS or is there something more that I need to do at my end. Thanks.
(In reply to comment #66) > >>It seems like shown UI does not reflect the fact that non-proxy and auth info > >>are specified per protocol. It would make sense to use master-detail idiom for > >>that. > I agree. The UI does not reflect this. However, is this a big deficiency. > Both > IE and Firefox don't allow setting non-proxy and auth info per protocol. Not true. Both IE and Firefox do allow to set auth info per protocol. They just don't show it in proxy configuration dialog and instead bring auth dialog on demand. However it is been said, that some proxies do need to know auth info in advance. In that regard, variant with a table that had auth info worked well. > >>Also, shown UI also don't imply that new protocols can be added. I believe that > >>table would serve better for such purpose. > Adding new protocols is a separate issue from how they are rendered in the UI. > If you have a look at the source code for the UI you will see that the > protocols > are added dynamically. If a new protocol was added to the core not a single > line of UI code would need to changed. And yet you can't tell that looking at the UI. Forms usually imply that elements aren't added dynamically. > If there is a compelling reason to render this information > differently I'm certainly open to suggestions. Table-based representation is more compact and better scale to the new protocols or other related parameters, like auth info. > The current implementation of the code does allow sharing of these setting. > Simply select all the hostnames in the table and click edit. A dialog will > pop up with a comma delimited list of all the hostnames. This text can > then be shared to whoever you want. Nice, but yet counter intuitive. I would of never thought of that. :-) > If we do decide to have automatic proxy detection and user browser settings > I don't think it will be a problem to have these radio buttons added to the UI. > The main issue for these enhancements is priority and time. These two > items will entail a fair bit of development work, which I don't think we > have the time for right now, unless some kind soul out there would like > to contribute the code for them? I was actually referring to the screen real estate. Form is already quite big and those new controls won't make it any smaller. > >>By the way, do we really need to have a separate proxy for https protocol? > Firefox and IE both allow these protocols to be configured separately so I > assume so. Do we have specific use cases? > In the current code drop I didn't intent to expose the api that the core > internet > and the internet UI use to communicate. In fact I put this code in internal > packages > and didn't export them for external use. That being said I'm not opposed to > having some kind of api being exposed. Its just that when it comes to exposing > apis I think we need to take a very cautious approach, since we will have to > live with this api for a very long time. Hmm. The one of the main points of this enhancement request is to provide an API to read those settings and NOT to set them globally for everyone on the same JVM. There are fair number of plugins, including Team/CVS/SSH, Mylar and others, who don't need any configured JVM proxy settings but instead need to be able to read these settings and use their own means to configure connections. > Woo hoo, these enhancement requests look great. Thanks for letting me know > about them! If these requests are implemented the Authenticator wont need to > cache this information any more. Cool. Note that those requests intended only to manage cached credentials. So, you still would have to do that caching. The reason I added those is to generalize UI, currently present under Team / CVS / Password Management
*** Bug 160497 has been marked as a duplicate of this bug. ***
I'll have a look at the patch once M5 is out of the way.
One of the things that would be nice to get into this version of the Internet Connection Management preference page would be the ability to add proxy protocols via an extension point. I've come up with an interface that I'd like to get this groups comments on. The extension would be pretty simple with just an id and class attribute. Here is an example of what the http protocol extension might look like. <extension point="org.eclipse.core.runtime.internet.proxy.protocol"> <protocol id="org.eclipse.core.runtime.internet.proxy.protocol.http" class="org.eclipse.core.runtime.internal.internet.HttpProtocol"/> </extension> The protocols being added would extend the following abstract class: public abstract class ProxyProtocol { /** * Loads protocol data from an Eclipse preferences store. * * @param preferences a preferences store. */ public abstract void load( Preferences preferences ); /** * Saves protocol data to an Eclipse preferences store. * * @param preferences a preferences store. * @param proxyData the proxy data to store. */ public abstract void save( Preferences preferences, ProxyData proxyData ); /** * Gets the proxy data for this protocol. * * @return returns the proxy data. */ public abstract ProxyData getProxyData(); /** * Enables this protocol. This usually would entail setting JVM system * properties. For the http protocol the "http.proxySet", "http.proxyHost" * and "http.proxyPort" properties would be set. * */ public abstract void enable(); /** * Disables this protocol. The usually means that JVM system properties * are removed. * */ public abstract void disable(); } The ProxyData class would contain the following String data along with getter and setter methods.: public class ProxyData { private String id; // The extension id of this protocol private String name; // The name of the protocol private String hostName;// The hostname of the proxy for this protocol private String port; // The port of the proxy for this protocol private String userid; // The user id to authenticate to the proxy server. private String password;// The password to authenticate to the proxy server. private String[] nonProxyHostList;// The non proxy host list. } Of course some protocols like SOCKS don't need all of these data fields and could set the unused ones to null. Anyway, this is just a first crack at defining an interface. Let me know what you think. Thanks.
It is probably should be tracked as a separate issue. Anyways, I would call the extension point org.eclipse.core.runtime.internet.protocol.proxy and made ProxyData (or better ProxyConfiguration) a final plain pojo what would be returned from this extension point trough some kind of factory or manger class. Also note that current attributes of the ProxyData are not sufficient (i.e. user id and password don't work for all proxies, so some kind of auth handler should used instead).
I've had an initial look at the patch. Like Eugene, I'm coming at this from a CVS angle and from that angle, its not clear to me how I woudl use the API in the patch. CVS can use either an HTTP or SOCKS proxy but needs to know which one to use. It also makes its own proxy connection so it needs to be able to retrieve the proxy information for a particular host. It is not clear to me how this would be done with the proposed API. I've also had a look at how update works and unfortunately, it works by overwriting the proxy system settings and setting the default authenticator. The patch does set the Authenticator but does not appear to do so for the other settings. As an earlier comment mentioned, it would be ideal to avoid setting either of these things and I agree. Unfortunatley, I don't think we can avoid it at this point. However, I definitely think it is a mistake to set the default authenticator on startup. I think it would be better to have a static method as API that clients can call to indicate that they require the system properties to be set. Once called, the plug-in will ensure that the system properties are kept up to date with the settings. The hope would be to eventually move all clients off of needing to call this method. The other known client is WTP. I don't know anything about the WTP scenarios but I assume that, since the code is coming from WTP, that the scenarios are being satisfied. However, I think it is in everyones best interest if we capture all the known requirements on a wiki page before proceeding. Once we have that, it will be easier to discuss what API and UI we need to meet these requirements. I have created the following wiki page (which is mostly empty): http://wiki.eclipse.org/index.php/ProxySupport I will write up the CVS and Update requirements tomorrow. Peter or Chris, can you document the requirments for WTP? I don't think we need too much here. I would just like to see a brief description of how proxies are used and perhaps a bit of code that illustrates the required API. I'll do the same for CVS and Update. Also, I think we need to stick to the basics here. Unfortunately, we don't have enough slack in the schedule to do anything but the bare minimum.
I think it would be good if some of the interruptible IO that you describe in http://eclipselowdown.blogspot.com/2007/01/responsive-remote-connections.html and in the CVS/Core Util class could be pushed down to this kind of level, too. http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.team.cvs.core/src/org/eclipse/team/internal/ccvs/core/util/Util.java?revision=1.48&view=markup http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.team.core/src/org/eclipse/team/internal/core/streams/PollingInputStream.java?revision=1.11&view=markup http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.team.core/src/org/eclipse/team/internal/core/streams/TimeoutInputStream.java?revision=1.8&view=markup At least if these can't be pushed down to a suitably generic level, can there be factories created which can then plug in this kind of implementation in the future? I'm sure that the update manager would benefit from this kind of IO too. Of course, the difference between these and the proxy settings is that these implementations have already been tested for some time :-) Alex.
(In reply to comment #74) > I think it would be good if [...] interruptible IO [...] could be pushed down Great idea, we'd love to see that too. Opened bug 173607 to track this separately. Put yourself on CC or vote for it if you'd also like it :-)
The only thing I don't understand is how I inject an authenticator to deal with non 407 responses. When Eclipse has got through the authenticating proxy server I will hit an authenticating web site. I need to be able to provide an authenticator for this request as the user has already logged into my application with the username/password required. So I think I need a way of providing an authenticator without any proxy setting values for the 401 responses. So perhaps we need two extension points, one for proxy settings and one for authenticator settings. On a separate point how will Eclipse interact with the "use browser settings" proxy setting in the 1.6 java control panel.
I have updated the wiki (http://wiki.eclipse.org/index.php/ProxySupport) with the requirements from an Update and CVS standpoint and outlined what the API could look like. Chris and/or Peter could you update the wiki with the information from WTP and adjust the Proposed API section as needed? Also, if anyone else has information they think is relevant, please feel free to participate. Unfortunately, we are at a point in the 3.3 time line that does not give us a lot or breathing room. I would say we have about two weeks at the most to hash out the requirements and get the code in shape to be released (so it would be good if we could have the requirements stated fairly quickly). Therefore, I think we really need to stick with the original issue of this request which is to consolidate the proxy preference pages that appeared in the Callisto release. Any other issues that require API will have to wait. As for the particular issue of providing extendability in the authenticator, this is a separate issue that needs to be tracked in its own feature request. Peter or Phill could you please enter a request for this?
If anybody opens up a request for the Authenticator issue (see eg. comment 38 and comment 41, but there are a couple of others) could he please put a statement here that cc'ing is possible for those interested in it? Thanks Richard
Based on the information we have collected so far on the Wiki page, I think we need to be conservative in what we do here for 3.3. The main issue we are addressing is the presence of multiple proxy preference pages. Therefore, I would propose that, for 3.3, we restrict ourselves to solving this particular issue. That is, we provide a preference page in the Platform for specifying the 3 proxy types that are used by CVS, Update and WTP (http, https and socks) and we provide a Core level API for accessing the values for each of these proxy types (type, host, port, username, password) and an event notification to let clients know when the values change. This would solve the issue for the user but leave the programming model for clients the same (i.e. if they modify the system properties and register an authenticator now, they will still need to do so). Peter, is this acceptable from a WTP standpoint?
Thanks, Michael, for setting up the wiki page. I think this page will be a very useful tool to discuss this feature. I'd like to response to your comment #79 from a WTP perspective. I think most of the points you made are acceptable, but I have some major concerns about not having an authenticator as part of the Eclipse internet plugin. 1) The Authenticator is an essential part of making a connection to a target host that is protected with basic authentication. We use it indirectly in WTP and many third party plugins use it as well when a connection is opened using a URL. 2) The original plan for this feature was to port the WTP internet plugin which includes the Authenticator. So I'm not sure why we would want to remove this functionality from the Eclipse internet plugin. 3) The Authenticator, unfortunately, is a singleton object in the JVM. Therefore, the Eclipse platform should really own and control this singleton object instead of having a number of plugins clobbering each other setting this singleton. My arguments above are just advocating that some form of Authenticator be present in the Eclipse internet plugin. I agree that the current behavior has some issues.(ie. credential caching.) I'd definitely be open to discussing a change in this behavior or perhaps even removing the caching altogether. I'd be interested to know what the behavior of Authenticator provided by the update manager plugin does. Perhaps this Authenticator could be used instead of the WTP one. I agree completely that it would be beneficial to have an API to retrieve proxy settings and have listeners for proxy change events. The main reason that I didn't provide one in my original code drop was because the WTP plugin does not have one and I thought that it was too late for defining new API for Eclipse 3.3. However, if there is time to add this API on the Eclipse 3.3 schedule then I'm all for it. I'd be interested in seeing a proposal for it. I agree that the new Eclipse internet plugin should not hook the IStartup extension as the WTP plugin does. However, some form of api should be provided by this plugin to set the global JVM system properties and set the Authenticator. Preferably, this could be done when the plugin is activated.
With respect to the Authenticator, I'm stuck on a very specific problem which is this: - WTP and Update depend on the use of the java.net.Authenticator which doesn't really support pre-specification or caching of passwords (i.e. it is better to prompt more often then it is to force the user to restart if they enter the wrong password). - CVS (and SSH2) depend on the JSch proxy classes which need the user name and password up front (i.e JSch proxy support works with Java 1.4). What this means is that we need a preference page that includes the username and password (at least for http and socks) so that CVS and SSH2 proxy support can be used. The user would then expect these passwords to be used when using the Java proxy support as well. I guess we could solve this with an Authenticator that used the provided user name and password for the proxies and prompted for other connections. This would give a unified experience across WTP, CVS, SSH2 and Update but would have the failing that, if proxy authentication failed, the user would not be prompted to authenticate but instead would have to somehow know to go to the preference page and reenter the authentication information (although one assumes that they entered it in the first place so it may be acceptable). The above described solution is not ideal but may be the best we can do given the limitations of the two proxy APIs we are using. However, any time prompt backs are involved, I consider the feature to be non-trivial (i.e. there always seem to be unforeseen problems that occur). Given that we are late in the cycle, I would be more comfortable with a solution that did not involve the Platform providing the Authenticator in 3.3. Hence my proposal was for an API that addressed the multiple preference page issue with the least amount of risk and while it doesn't make things much better for clients, doesn't make it any worse than it already is. Once 3.3 ships, we could get an early start on get the Authenticator story right. Anyway, anything we do for this feature in 3.3 requires PMC approval. I will seek their input on the following possibilities (if you think I missed a possible solution, let me know): 1) The Platform provides only the preference page settings and it is up to clients to set the JVM properties and the authenticator as they do today. 2) The Platform provides the preference page and settings and a means for clients to indicate that that the Authenticator should be set and the JVM properties should be set and kept up-to-date. The Authenticator would just prompt when a password is required (as the Update Authenticator does). 3) Same as 2 but the Authenticator uses the user name and password from the preference page when proxy connections are attempted.
Excuse my ignorance ... what is it that the Authenticator does that Platform.getAuthorisationInfo(url,realm,scheme) doesn't do?
It sounds like we are in agreement on most issues, but I was a bit confused by your discussion about the Authenticator. I guess I'm not clear on how you use the Authenticator with Jsch. For WTP the Authenticator is rarely used to authenticate a proxy. If the proxy did require authentication the user would normally specify the credentials in advance on the proxy preference page. For WTP the main purpose of the Authenticator is prompt the user when hosts other than proxy server require authentication. For example if the http protocol is used to get a file from a Web server and this server has basic authentication enabled then this server will request authentication. The java.net code will kick in and call the Authenticator to get the userid and password. My example here is just to clarify our usage of the authenticator and make it clear that our usage of it is quite separate from proxy authentication. Therefore, I think your option #2 is pretty close to what we what. Which is: 1) The user should be able to specify proxy information( hostname, port, non proxy host list, userid, password) on the internet preference page for http, https, and socks. For WTP we don't need an API to access this information, since everything we need is in the JVM system properties, but having an API doesn't hinder us so I'm all for it. 2) We need some sort of Authenticator that will prompt for user id and password. As I stated previously, it doesn't need to cache credentials. The code that I dropped should do everything for option 2 except the following: 1) The Authenticator caching would be removed. This just requires the deletion of a few lines of code. 2) The addition of an API to retrieve the proxy information. The ProxyData class in the code drop contains all the proxy information required here. 3) An additional API for clients to set the JVM system properties.
(In reply to comment #82) > Excuse my ignorance ... what is it that the Authenticator does that > Platform.getAuthorisationInfo(url,realm,scheme) doesn't do? Authenticator, is a piece of implementation of java.net.* API, which has very little todo with storing auth data functionality provided by Platform.getAuthorisationInfo() BTW, I've been just told that Platform.getAuthorisationInfo() going to be deprecated after Eclipse 3.3.
(In reply to comment #83) [skipped] > 1) The user should be able to specify proxy information( hostname, port, non > proxy host list, userid, password) on the internet preference page for http, > https, and socks. For WTP we don't need an API to access this information, > since everything we need is in the JVM system properties, but having an API > doesn't hinder us so I'm all for it. > 2) We need some sort of Authenticator that will prompt for user id and > password. As I stated previously, it doesn't need to cache credentials. Can we please track Authenticator in a separate report? I believe any Authenticator implementation should be a consumer of proxy configuration API discussed in this report, but should NOT be part of this API.
(In reply to comment #81) > What this means is that we need a preference page that includes the username > and password (at least for http and socks) so that CVS and SSH2 proxy support > can be used. FYI, CVS pserver and ssh2 expects the http proxy, which supports HTTP's CONNECT method. So, the settings for "https" will be refered from CVS plug-in.
I have raised a bug report 174129 for tracking the authenticator issue.
regardless of the authenticator issue will the new preference page inherit the proxy settings from the current browser settings. In the RCP world this is a major issue walking most users throught setting up proxy settings.
I think we now have a good feel for what the Core level API should look like and we understand the issues related to the Authenticator. I have updated the wiki (http://wiki.eclipse.org/index.php/ProxySupport) with some questions regarding the preference page (new section at the bottom) in the patch (and how the fields there translate into the proxy settings). Peter, could you have a look at this?
Regarding comment 88, I agree that inheriting the systems settings, if there are some, would be good. However, that is out of the scope of this request. Could you log a separate enhancement request for that?
Michael et al, Peter and I have both made a few updates to the Wiki over the course of the day, hopefully of the sort that help us home in on the necessary minimum for Eclipse 3.3 vs. add more uncertainty or debate. In most, but not all :), cases we've prefixed our comments by [PM] or [CB].
Added bug 174261 to request the preference page has an option to use existing browser settings.
Created attachment 59190 [details] Refactoring of contributed code to include API etc. OK, here's what I have based on the various conversations here and on the wiki. The zip includes both the Net plug-ins (org.eclipse.net.core and org.eclipse.net.ui) and some JSch plug-ins that are also being worked on (they are included since they use the API that has been added to the NET plug-ins). Here are some points about the code: 1) I haven't done much testing so, although I think the code should work, chances are there are bugs. 2) The API requires that a client calls an init method. However, I am hoping to get approval to call the init from the application (for the SDK this is the IDE application). This will give SDK consumers/extenders what they want but also give some flexibility to RCP consumers). 3) I've used the authenticator from update since it is simple and well tested. 4) I've cached user credentials in the keyring so we don't need our own encoder. I'm planning on starting the project creation process early next week so if you have any objections to the plug-in names, now would be a good time to voice them. Once that's happened (and if everyone agrees with the general shape of things), we can get down to the serious shake-out and testing and work towards getting the plug-ins in the build.
Michael, can you please post screenshot for the current configuration UI?
I haven't changed the UI so it looks the same as in this link: https://bugs.eclipse.org/bugs/attachment.cgi?id=58137 At this point, I'm more concerned with getting the API sorted out so we can obtain PMC approval for it. Once we have that and get the plug-ins created, we can discuss whether changes are needs to the layout of the preference page. One related things I did forget to mention was that I removed the empty Internal preference page that parented the proxy page and put the page in General (called Network Connections). The SSH2 page is then a child of that page.
(In reply to comment #93) > Created an attachment (id=59190) [details] > Refactoring of contributed code to include API etc. > OK, here's what I have based on the various conversations here and on the wiki. Is it too late to add the method IProxyData getProxyData(String host, String type) to IProxyManager ? If strings like ".mozila.org, .net.nz, 192.168.1.0/24" are allowed for "No Proxy for", every plug-ins, who uses org.eclipse.net.core, must write a little bit complex code by themself.
Thanks for pointing that out. I had intended to have something like that in there. Here are some options: IProxyData[] getProxyDataForHost(String host) - would return an empty array if the host is in the non-proxied list. Otherwise, it would return all proxies that have been specified (which could still be an empty list) boolean requiresProxy(String host) - returns true if the host is not in the non-proxied list (or matches an entry in the list since the Java non-proxied host list supports the use of * so we will as well). IProxyData getProxyDataForHost(String host, String type) - returns the data for the host or null if the type is not known, has no proxy specified or the host is in the non-proxied list I think all three would be useful to have (although the middle one may be redundant since the last one would allow clients to determine whether a proxy was required as well). How does this sound?
(In reply to comment #97) > IProxyData[] getProxyDataForHost(String host) - would return an empty array if ... > boolean requiresProxy(String host) - returns true if the host is not in the ... > IProxyData getProxyDataForHost(String host, String type) - returns the data for I agree with you that second one may be redundant, but at least the first method must be worth of sneaking into 3.3 release, if possible.
I have added the first and third options I mentioned in comment 97. I have also had the projects created in the repository and put the latest versions of the code there. The projects are: org.eclipse.net.core org.eclipse.net.ui org.eclipse.net.tests (empty now but I will add tests soon) Over the next week, I will be writing and performing some tests in preparations to getting the code added to the build. However, I don't have a proxy set up yet and will probably not have much variation in the proxies I am able to test with. It would be very helpful if interested parties could help out in testing this. For the time being, you will need to open the preference page to ensure that the proxy settings are placed in the system properties (this will be fixed when the plug-ins are added to the build). Also, I'm moving the bug to the Team component since that is the component in which the projects were created.
I've had to change the name of the projects to the following: org.eclipse.core.net org.eclipse.ui.net org.eclipse.core.tests.net I've also added some automated tests and done some basic manual testing. I still haven't been able to set up an HTTP or HTTPS proxy so it would be very helpful if this could be tested by other interested parties. I've also changes the IProxyManager to IProxyService and have made it available through the OSGi service registry. The UI plug-in has an example of how to access the service.
Michael, just a few comments/questions... In comment 99 you moved this RFE to the "Team" component. Is this the strategic component to manage the org.eclipse.*.net plugins? If so, I would have thought "Runtime" to be a more intuitive choice from the perspective of the community at large, especially when it comes to opening bugs and yappin' on mailing lists. This enhancement is use by, but not specific to, Team. I opened RFE bug 175171 to remove the internet proxy/authenticator plugin from WTP in M6. I believe Peter is going to grab your latest stuff from the repository next week, locally blow away his org.eclipse.wst.internet.proxy plugin, and try a few tests with CCProxy. Is there any news from the PMC or otherwise on getting some minimal internet configuration logic to run at core startup time - Namely JRE variable initialization and Authenticator initialization? Thanks - CB.
Chris, Sorry for not communicating more on this. We have come up with a strategy by which the proxy service can be disabled using a VM flag. When enabled, the Java system properties are set and an Authenticator registered. The proxy service will be initialized by the application (in our case, the IDE application). Since nothing can really happen until the application starts up, this should be adequate for WTP. RCP apps would need to perform the initialization (which is basically to attempt to access the IProxyService so that the Core plug-in gets loaded. As for why this is in Team, it is simply because I have been working on it and that is what I have commit rights for. The justification for this was simply that we didn't have time to work out all the details of were it really should be. Once 3.3 ships, we can revisit this. One other point of interest is that the plug-ins have just been added to the build today and should be in the next integration build. Another important point to note is that we have one week after EclipseCon to make API changes so the earlier you can verify that it meets your requirements, the better.
Created attachment 60292 [details] Patch to IDE Application Here's the proposed change to the IDE application. It ensures that the proxy service has been initialized by referencing the service just before the workbench advisor checks for updates.
Created attachment 60293 [details] Patch to Update This is the proposed patch to Update to remove the proxy settings from Update, deprecate proxy related API and use the new proxy support from that deprecated API.
*** Bug 176548 has been marked as a duplicate of this bug. ***
(In reply to comment #105) > *** Bug 176548 has been marked as a duplicate of this bug. *** > According to recommendation of Chris Brealey I will post my enhancement request to this bug too to be probably considered as additional requirement. We are using WTP WebServicesExplorer as testing tool for web services. Works fine when using standard development environment, where we have access via HTTP to the server providing the web services. Within integration environments, and sometime for queries in production environment, the servers are only accessible via HTTPS and client-certificates. The current implementation of org.eclipse.wst.ws.internal.explorer.platform.wsdl.transport.HTTPTransport does support BasicAuth and proxies, but nothing for certificates. We would require: - configure a specific trust store (and password) (as server certificates are signed by a custom CA) - configure a specific keystore (and password), where our client certificates can be stored. - Optionally configuring a hostname verifier, as we are accessing the server via SSH tunneling, so server-certificate does not match the current host (e.g. localhost). Verifier can be default, or one ignoring server name, or a contributed one.
I gave the new proxy API a first try and must say, I really like it! However, there is a couple of issues I wanted to share with you: 1. The presence of the system properties "socksProxyHost" and "socksProxyPort" is a problem for me. I am using Apache HTTPClient for all connections. HTTPClient is not using URLConnection at all, but since its using Sockets, those System Properties have a direct impact. The issue I have is, that you can not specify non-proxied-hosts. I found a comment "There does appear to be a way to set the non-proxy hosts for Socks" in ProxyType.java. Will this be fixed for M6? Otherwise the proxy exclusion list is useless for all clients of HTTPClient (I guess there are a lot using it). 2. I see a couple of warnings when adding the net.core and net.ui plugin to my app: !ENTRY org.eclipse.ui 4 4 2007-03-14 17:34:32.952 !MESSAGE Invalid preference page path: Network Connections !ENTRY org.eclipse.osgi 2 1 2007-03-14 17:34:34.015 !MESSAGE NLS missing message: InternetCategoryPage_0 in: org.eclipse.net.internal.ui.messages !ENTRY org.eclipse.osgi 2 1 2007-03-14 17:34:34.030 !MESSAGE NLS missing message: InternetCategoryPage_1 in: org.eclipse.net.internal.ui.messages 3. Any reason the controls in the preferences dialog are not using a horizontal fill layout? Otherwise, great work!
Btw I was using the code from the "Refactoring of contributed code to include API etc." attachment in this bug. Not sure if there is a more recent version.
Btw, I think the ProxyData should include a getter and setter for "domain". HTTPClient supports NTLM authentication, which asks for a "domain" together with userid and password (of course the UI needs an update too in that case).
I forgot to mention that I was always checking "Use this proxy for all protocols". As soon as I uncheck this option, the socks-properties are not set and thereby don't interfere with HTTPClient.
Ben, the code has been modified since then. The latest version is in the latest I build. If you could try that out, that would be great. Regarding the SOCKS non-proxied hosts, there doesn't seem to be a way using properties to indicate that Java should respect this list (at least, I couldn't find one). The JSch proxy does respect the list when making socks proxies. I agree that this is a problem but I'm not really sure how to go about solving it. Ideas are appreciated. Interestingly enough, there does seem to be a way to disable the Java SOCKS proxy in 1.5 using an instance of java.net.Proxy that has a type DIRECT and creating a Socket on that proxy. You may be able to use this to bypass the Java proxy. Unfortunately, we can't do this in our code unless we change our environment to 1.5 (it is currently 1.4). Regarding the HTTP authentication domain, this is problematic as well since Java does not support it but the HttpClient does. If we add the domain to the general data, users may be confused about when it gets used and when it doesn't. My first thought would be to have a separate preference page for the HttpClient that allowed the user to specify this additional information although I would say it is unlikely we would put it into 3.3, just because of the timing. Regarding the preference page layout, I suspect the reason is lack of knowledge about the horizontal fill layout (since the grid layout seems to do everything) however this was contributed by Chris so perhaps he can answer that question.
Seems to work fine so far with this weeks IBuild. I am sill getting these warnings though (my RCP Target is the IBuild too): !ENTRY org.eclipse.osgi 2 1 2007-03-15 21:55:08.843 !MESSAGE NLS missing message: InternetCategoryPage_0 in: org.eclipse.ui.internal.net.messages !ENTRY org.eclipse.osgi 2 1 2007-03-15 21:55:08.843 !MESSAGE NLS missing message: InternetCategoryPage_1 in: org.eclipse.ui.internal.net.messages Regarding the layout: I was suggesting to use a Horizontal Fill GridData for the controls to make them shrink as soon as the dialog gets bigger.
s/shrink/grow
(In reply to comment #107) FYI, we are discussing the problems of the JVM socksProxyHost System Property now on bug 177550. In short, it looks like any bundle or library that is capable of doing its own Proxy support (like users of Jsch and Apache httpclient) should be responsible for disabling the JVM's proxy support such that it can do its own thing. org.eclipse.wst.ws.internal.explorer.platform.wsdl.transport.HTTPTransport may also be a candidate that might want to disable the System properties.
(In reply to comment #114) > (In reply to comment #107) > FYI, we are discussing the problems of the JVM socksProxyHost System Property > now on bug 177550. In short, it looks like any bundle or library that is > capable of doing its own Proxy support (like users of Jsch and Apache > httpclient) should be responsible for disabling the JVM's proxy support such > that it can do its own thing. > > org.eclipse.wst.ws.internal.explorer.platform.wsdl.transport.HTTPTransport may > also be a candidate that might want to disable the System properties. > Disabling the system property is not really stable (e.g. what about multiple Threads connecting at the same time, some requiring the system property, some not).
(In reply to comment #115) We know it has threading issues, and in fact the patch on bug 177550 is able to use the much better solution through Proxy.class when running on Java 1.5. But when running on 1.4, we believe it's better to have a solution that works most of the time than one that is known to fail. We're happy to continue discussing this on bug 177550.
Ben, I just fixed the missing message problem and will investigate the layout. Regarding your earlier question about HTTP authentication domains, I found the description of how this is supported by the Apache HttpClient but I haven't been able to find any examples of an application that surfaces this to the user. For instance, FireFox doesn't surface this notion. Do you know of any applications that do present this choice to the user?
(In reply to comment #117) > Ben, I just fixed the missing message problem and will investigate the layout. Great! I should be able to look into the layout myself too tomorrow if you don't have enough time for that. > Regarding your earlier question about HTTP authentication domains, I found the > description of how this is supported by the Apache HttpClient but I haven't > been able to find any examples of an application that surfaces this to the > user. For instance, FireFox doesn't surface this notion. Do you know of any > applications that do present this choice to the user? > I am not sure if Firefox is supporting NTLM authentication at all. Google seems to have a couple of interesting results from a search "firefox ntlm". I am using this in RSSOwl 1 (http://www.rssowl.org/download) and have never seen this in any other application, however I never really looked carefully because I am not using NTLM at all.
I'm happy to accept a patch for the preference page layout :-) Regarding NTLM, given that it is not widely used and is only partially supported by HttpClient (supports v1 but not v2) and is not supported by Java, I don't think it warrants our attention at this time (considering that our API freeze is next week). We may revisit the issue in a subsequent release.
I was surprised by comment #119 that implied that Java did not support NTLM. It has been supported since 1.4.2 according to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4626557 and is also mentioned in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4857110
Jim, thanks for the pointers. I also found this link (http://java.sun.com/j2se/1.5.0/docs/guide/net/properties.html) which describes how to use domains in Java. It appears that there is a system property for this but it also indicates that the domain can be encoded in the user name. I would suggest that other clients such as those using HttpClient) should support this user name format as well, at least for 3.3.
Btw I think the proxy UI is using the TableLayout which afaik gets breaking API changes in M6 (see Bug 171824). I will wait until next weeks IBuild before working on the layout to consider this change.
Btw 2 UI related suggestions: - items from the non-proxied-host list should be editable on doubleclick (as e.g. fonts are) - it should be noted that wildcards ? and * are supported for non-proxy-hosts (e.g. use ControlDecoration) - is "userid" even a word? I would rather use "username" instead
Ben, I am in agreement with everything you have said in comment 123. I haven't spent much time looking at the UI since my main focus was to get the API done for M6.
(In reply to comment #124) > Ben, I am in agreement with everything you have said in comment 123. I haven't > spent much time looking at the UI since my main focus was to get the API done > for M6. Michael, Ben, are you considering to use table widget instead of dynamically creating form elements for different proxy types like in the one of the first reworks of this UI?
At this point, given that we only have 3 supported proxy types, I don't see the advantage of going with a table. Also, I think it is worthwhile to stick with a format that is similar to other applications. None of the applications I have seen use a table (e.g. FireFox, IE).
(In reply to comment #126) > At this point, given that we only have 3 supported proxy types, I don't see the > advantage of going with a table. Also, I think it is worthwhile to stick with a > format that is similar to other applications. I would agree with you if form would of been created statically. But if those elements could change driven by some external configuration or extension points table may be a better representation for that data. > None of the applications I have > seen use a table (e.g. FireFox, IE). Maybe it is just a limitation of the UI framework Firefox is using...
I don't think it has anything to do with how it is implemented. I think that for the number of support proxies (3), it is easier for the user if they see all three types and can put the values in the appropriate field. I think a table might make sense if you had a larger number of proxy types or if the user could specify different hosts for the same proxy type (which they can't). I have just versioned everything for the M6 practice build. I think it is time to mark this bug as fixed. For any issues that come up (such as those mentioned by Ben) could you please log new bug reports. Feel free to drop a pointer here so interested parties are informed about them.
Filed Bug 177897 for the UI related issues.
Anyone interested in the evolution of the UI in 3.3 related to this feature should have a look at bug 177897.
*** Bug 88017 has been marked as a duplicate of this bug. ***
*** Bug 97423 has been marked as a duplicate of this bug. ***
