Community
Participate
Working Groups
I work behind an authenticated proxy at work, and at home I can either go through the proxy through my VPN, or go straight to the internet. I find that Mylar and Eclipse have trouble when I try to define an external URL (like the repo URL), when I'm behind the proxy. It just says "UnknownHostException: bugs.eclipse.org". I've defined all of my proxy settings correctly, I believe. I have no trouble Before version 0.9.1 of Mylar, I was at least able to have my Bugzilla repo defined while off the proxy (from home), but afterwards it could still sync even while on the proxy. It was only JIRA that still failed to sync while on the proxy. Now, on version 0.9.1, I can't do anything with task repositories while on the proxy. The settings won't validate, and syncs fail with the UHE. One thing that seems curious to me is that with 0.9.1, there are optionally separate proxy settings for each task repository, which seems odd, as you're still coming from the same place, no matter where the repo is. The proxy settings for each repo shouldn't be different. The other curious thing is that it refers to the "Install/Update" settings (in the Preferences, I assume). In those settings, you can set the proxy host/port, but not the user/pwd. If I don't have the "Install/Update" checkbox set, then I can set the user/pwd for each repo (which is again redundant, as that shouldn't change for each repo). If I enter those proxy values while on the proxy, it won't let me store them, as I get "No Bugzilla server found at url". Also note that when I plug that same URL into my web browser, it has no trouble getting there. It almost seems like the URL validation is not done through HTTPClient, in a way that is not using the proxy.
Is this an http or socks proxy?
I have an http proxy.
Rob, I tested with local squid and neither bugzilla, track nor web connector is working with proxy. More over, I can't even Finish properties page for bugzilla and track if I uncheck "use install/update" setting. Finish is disabled.
Okay, I'll be testing today against squid and will get this resolved asap. Regarding the finish in the proxy config, the url for the proxy server needs to start with http(s):// just like the repository url. (not ideal but is required by the platform when storing the credentials). If you know how to work around this I'd be interested.
(In reply to comment #4) > Okay, I'll be testing today against squid and will get this resolved asap. > Regarding the finish in the proxy config, the url for the proxy server needs to > start with http(s):// just like the repository url. (not ideal but is required > by the platform when storing the credentials). If you know how to work around > this I'd be interested. I'm not certain what you mean here. Are you saying that the user needs to enter the proxy URL with "https://<proxyhost>"? I don't see anywhere where I enter an actual URL for a proxy. I only see fields to enter the proxy host name (not the full URL).
(In reply to comment #4) > Regarding the finish in the proxy config, the url for the proxy server > needs to start with http(s):// just like the repository url. You could at least shown some explanation in the status when validating page. > (not ideal but is required by the platform when storing the credentials). > If you know how to work around this I'd be interested. No, it doesn't. Mik and I changed TaskRepository, so it stores proxy into the same credentials as connector (same entry in key chain). and even that entry can refer to non-http repository. See TaskRepository class for details.
Yes, you're right Eugene. Shortly after posting I realized my mistake and will check in a fix shortly (and with any luck a fix for these proxy issues). :)
(In reply to comment #3) > Rob, I tested with local squid and neither bugzilla, track nor web connector is > working with proxy. More over, I can't even Finish properties page for bugzilla > and track if I uncheck "use install/update" setting. Finish is disabled. > Yes, I'm having exactly the same problem.
Okay thanks for confirmation Torkild. We've narrowed the problem down to a failure to make the initial https connection via the proxy (Squid appears to be the most popular so that is what I'm testing against). The following faq is related: http://www.squid-cache.org/Doc/FAQ/FAQ.html#toc11.45 It appears as though the client isn't making a proper initial connect request but rather encrypting right from the start. This morning I'll look into why and how we can force option 2 in that faq entry. Sorry for the delay on this one as I know it is affecting many of you. I'll have this fixed as soon as possible. :)
Eugene, do you have time to test the changes I've made to HEAD against your proxy? I've testing regular and https proxy and all seem to work now. The only thing I haven't been able to test here is authenticated proxy support. I haven't been able to get the basic authenticator to work on my test squid install: 2006/12/05 13:05:01| Ready to serve requests. 2006/12/05 13:05:01| WARNING: basicauthenticator #5 (FD 10) exited 2006/12/05 13:05:01| WARNING: basicauthenticator #4 (FD 9) exited 2006/12/05 13:05:01| WARNING: basicauthenticator #3 (FD 8) exited 2006/12/05 13:05:01| Too few basicauthenticator processes are running FATAL: The basicauthenticator helpers are crashing too rapidly, need help!
fyi, I've inadvertently re-created the cert problem: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target investigating...
Okay, tracked down problem and as a result had to come up with another solution for ssl proxy support. Eugene, if you could test with authenticated proxy that would be great.
I just did a sync in my 3.3m3 instance and tried a test with a Bugzilla repo (eclipse.org). It still fails with the "No bugzilla server at url" message. I tried setting a breakpoint in WebClientUtil.setupHttpClient(). I saw it set the proxy host and port, but not the proxy principal or credentials. When it finally executed the method, it got "Unrecognized SSL message, plaintext connection?". Related to this, in my 3.2 instance, when I try to validate a JIRA connection, I believe it's using the XmlRpcCommonsTransport class to send an XML message. This doesn't use the proxy at all. I would verify this in my 3.3m3 instance, but for some reason the JIRA and Trac connectors aren't available in my 3.3m3 instance.
Created attachment 55106 [details] test
Please ignore that. I am just testing proxy
Okay. Bugzilla and JIRA are working. Track and web connector does not work. Here is the details: Bugzilla (eclipse.org https) -- when using anonymous, repository validation always saying that credentials are valid and I don't see any requests going out -- updating repository attributes is working -- task and query synchronization and opening editors are working with correct settings Trac (http) -- validation does not work for both, install proxy and repository proxy (host not found error) -- updating attributes does not work, so I cant' test query Web connector (http) -- synchronization and preview does not work for both install and repository proxy JIRA -- as expected does not work with ide proxy settings -- when required properties are added, synchronization and editors are working (bugzilla is still working with these properties) I have no idea why it does not work for David.
Fix for http proxy committed. Looking into anonymous proxy issue...
David, you may not have been fully synched on your last attempt.
Rob, that was for an anonymous bugzilla account. Probably not related to proxy, since my squid require basic auth.
(In reply to comment #18) > David, you may not have been fully synched on your last attempt. > Nope, no difference. There was no change to WebClientUtil, so I didn't expect it to work. Let me ask about how you're testing this. Do you have Squid running on a separate box from where Eclipse is running? Are you running Wireshark to monitor all of the HTTP connections coming from your box? If any of those HTTP connections are not setting all of the correct proxy headers, then it won't work. I think what might be happening here is that you have Squid running, and if you connect through Squid, it probably works, but you're not verifying that there are not other connections you're not aware of, that are NOT using Squid.
David, yes I have squid on a separate box and in addition to that I disabled connections from my test machine to anything but squid server on the router. So, there was no physical connections possible to the outside world and I don't have to monitor any headers to verify that. December 5th Rob made 3 changes in WebClientUtil. One is almost an hour after your comment #13. So, I am not quite sure where you updating from... :-)
(In reply to comment #21) > David, yes I have squid on a separate box and in addition to that I disabled > connections from my test machine to anything but squid server on the router. > So, there was no physical connections possible to the outside world and I don't > have to monitor any headers to verify that. > > December 5th Rob made 3 changes in WebClientUtil. One is almost an hour after > your comment #13. So, I am not quite sure where you updating from... :-) > I don't know why you consider the time of comment #13 to be relevant, as I said in #20 that the changes made no difference. If WebClientUtil doesn't call "client.getState().setProxyCredentials()", I don't see how it could work (unless it's somehow constructing the headers manually). That method is only called in two places in the Mylar code base, as far as I can see (sync from last night), in MylarUsageMonitorPlugin.java and JiraWebSession.java.
wrt proxy authentication ,currently in head, proxy credentials are being set in WebClientUtil.setupHttpClient() (line127) (http proxy) and also being called at line 85 in SslProtocolSocketFactory (for https connections via proxy).
Created attachment 55149 [details] mylar/context/zip Guess I should use the tool! :) Please see context....
(In reply to comment #23) > wrt proxy authentication ,currently in head, proxy credentials are being set in > WebClientUtil.setupHttpClient() (line127) (http proxy) and also being called > at line 85 in SslProtocolSocketFactory (for https connections via proxy). > Well, if you say it's line 127, then there's definitely something wrong with how I'm getting this from CVS. In my copy, "setupHttpClient()" doesn't even begin until line 189. My copy calls "client.getState().setCredentials()", but not "client.getState().setProxyCredentials()".
Should be fixed. Leaving open until we receive confirmation.
Ok, I was confused about "Synchronize" vs. "Update". I won't be able to verify this until this evening (one day, I'll try to get someone to address the problem that the CVS plugin doesn't work in the proxy :) ). I did view the file through the CVS browse page, and it certainly looks closer than it did before.
David, cvs plugin does work trough socks which can be tunneled trough proxy if you have an external host to tunnel to...
Sigh. I didn't notice the CVS plugin had separate proxy settings from everything else. I verified I can sync and get the latest code through the proxy. I've verified I can validate a Bugzilla repo (Eclipse.org) through the proxy. I then right-clicked in the Task Repo view and tried to add another repo, but it gives me a NPE. It doesn't even give me a stack trace, so I would have to dig a bit to find that. Concerning the original problem, I can confirm it's fixed for the Bugzilla connector at least.
Okay, thanks David. I'll mark this one resolved.
