Community
Participate
Working Groups
Created attachment 282125 [details] Screenshot - Check for Update - Proxy Authentication Error If I set up a proxy in Windows System Preferences that supports the, and only the, authentication schemes Negotiate (Kerberos) and NTLMv2 (in that exact order), Eclipse will automatically detect it, but the "Check for Update" function will not work correctly (see screenshot). The following error appears for many update sites: HTTP Proxy Authentication Required When can we expect native support for the above proxy authentication schemes in future Eclipse releases?
I don't think NTLM should be supported. Microsoft themselves discourage using it and state in their NTLM specification[1]: "applications are generally advised not to use NTLM". ([MS-NLMP] - v20190923 NT LAN Manager (NTLM) Authentication Protocol, 23 Sep 2019.) If you want to use NTLM, try the cntlm proxy. [1] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/b38c36ed-2804-4868-a9ff-8dd3182128e4
Ok, thanks, and what about the native support of Negotiate (Kerberos)?
*** Bug 561223 has been marked as a duplicate of this bug. ***
I suspect this issue will just rot sitting in p2. In the end, p2 uses ECF for all the communication so it would need to be supported in ECF. Is this statement correct Mat?
(In reply to Ed Merks from comment #4) > I suspect this issue will just rot sitting in p2. In the end, p2 uses ECF > for all the communication so it would need to be supported in ECF. Is this > statement correct Mat? I don't know if this is correct, I am not familiar with p2's update-checking code.
All of p2's transport is funneled though org.eclipse.equinox.internal.p2.repository.Transport which is primarily implemented by org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport: /** * RepositoryTransport adapts p2 to ECF file download and file browsing. * Download is performed by {@link FileReader}, and file browsing is performed * by {@link FileInfoReader}. */ public class RepositoryTransport extends Transport { I'm very familiar with both from heavy usage in Oomph where we also implement Transport via org.eclipse.oomph.p2.internal.core.CachingTransport which delegates to p2's RepositoryTransport. We also use ECF directly in org.eclipse.oomph.setup.internal.core.util.ECFURIHandlerImpl. In this class we use both org.eclipse.ecf.core.util.Proxy and org.eclipse.core.net.proxy.IProxyData but it's primarily driven by ECF's proxy support. It's used for org.eclipse.ecf.filetransfer.IRemoteFileSystemBrowserContainerAdapter.setProxy(Proxy) and org.eclipse.ecf.filetransfer.IRetrieveFileTransferContainerAdapter.setProxy(Proxy). This is the primary mechanism by which setup resources are loaded. Looking at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.getLastModified(URI, IProgressMonitor) as a basic example, it uses org.eclipse.ecf.core.security.ConnectContextFactory.createUsernamePasswordConnectContext(String, Object) to provide context when delegating though p2's ECF layer. In any case, it should be clear up front that no one is likely to spend time on an issue such as this. Firstly, it's a heavy burden with no clear benefit to the person shouldering that burden. And secondly, one needs an environment in which to reproduce the problem, making the burden even heavier. I'm certainly not going to mess with my machine's configuration to try to replicate the context because I can try to find a way to fix it. I'm already annoyed that I get this in my log every time I launch anything: !ENTRY org.eclipse.core.net 4 0 2020-03-20 06:14:29.458 !MESSAGE WinHttp.GetProxyForUrl for pac failed with error 'The proxy auto-configuration script could not be downloaded ' #12167. This comes from my last efforts to fix proxy problems by first trying to reproduce them with Fiddler. I'll mark this as an enhancement request and will strongly suggest that anyone interested in this capability either contribute the implementation themselves or hire an expert to contribute the implementation.
How is the issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=544447 (thx to Mr. Thomas Wolf for the hint) related to the issues described here? Obviously it has already been fixed there. Why does "Check for Update" still not work with Eclipse 2019-12 in this case? For your information: The proxy server with which "Check for Update" fails in this case responds to the following curl command as follows: curl -X CONNECT -i --proxy-ntlm --proxy <POXY_HOST>:<PROXY_PORT> <HTTPS-URL> HTTP/1.1 407 Proxy Authentication Required Server: squid/3.5.21 ... Proxy-Authenticate: Negotiate Proxy-Authenticate: NTLM ...
(In reply to phorcys from comment #7) > How is the issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=544447 (thx > to Mr. Thomas Wolf for the hint) related to the issues described here? > Obviously it has already been fixed there. Why does "Check for Update" still > not work with Eclipse 2019-12 in this case? > > For your information: The proxy server with which "Check for Update" fails > in this case responds to the following curl command as follows: > > curl -X CONNECT -i --proxy-ntlm --proxy <POXY_HOST>:<PROXY_PORT> <HTTPS-URL> > > HTTP/1.1 407 Proxy Authentication Required > Server: squid/3.5.21 > ... > Proxy-Authenticate: Negotiate > Proxy-Authenticate: NTLM > ... As already stated by Ed, it is very hard to reproduce these kind of issues without access to the right environment. So I am afraid that best changes to get this issue fixed it that you start debugging yourself. You could start by checking: - What are the versions of the HttpClient plugins in your environment (does it include the required fixes) - Are the HttpClient win plugins installed - Does the proxy work if you manually provide it in the Eclipse settings (including credentials)
Okay, here's what I tried: - Download the latest eclipse-java-2020-03-R-win32-x86_64 - Check whether the following plungins are available in "plugins" subfolder (yes, they are): - org.apache.httpcomponents.httpcore_4.4.12.v20200108-1212 - org.apache.httpcomponents.httpclient_4.5.10.v20200114-1512 - org.apache.httpcomponents.httpclient.win_4.5.10.v20200113-2105 - org.eclipse.ecf.provider.filetransfer.httpclient45_1.0.200.v20200212-0036 - org.eclipse.ecf.provider.filetransfer.httpclient45.win32_1.0.100.v20200212-0036 1) - Configure my test proxy with SPNEGO and NTLM, so that the proxy responds to the following curl command as follows: curl -X CONNECT -i --proxy-ntlm --proxy <POXY_HOST>:<PROXY_PORT> <HTTPS-URL> HTTP/1.1 407 Proxy Authentication Required Server: squid/3.5.21 ... Proxy-Authenticate: Negotiate Proxy-Authenticate: NTLM ... - Start via eclipse.exe - Enter the correct manual proxy settings (Host, Port, Auth, User) for HTTP and HTTPS schemes via menu: Window -> Preferences -> General -> Network Connections -> Active Provider -> Manual - Check for Updates via menu: Help -> Check for Updates - It works! :) The win extension of the standard apache httpclient library can read the authentication (User, Password) directly from the operating system, see: org.apache.httpcomponents.httpclient.win_4.5.10.v20200113-2105/org.apache.http.impl.client/WinHttpClients. It would be nice if eclipse could do the same in this case so there would be no need for user interaction. 2) - Configure my test proxy with SPNEGO only, so that the proxy responds to the following curl command as follows: curl -X CONNECT -i --proxy-negotiate --proxy <POXY_HOST>:<PROXY_PORT> <HTTPS-URL> HTTP/1.1 407 Proxy Authentication Required Server: squid/3.5.21 ... Proxy-Authenticate: Negotiate ... - Do the same as in 1) (see above) - It does NOT work (see screenhot)! :( I debugged myself and I noticed the following strange default settings in class org.eclipse.ecf.provider.filetransfer.httpclient45_1.0.200.v20200212-0036/org.eclipse.ecf.internal.provider.filetransfer.httpclient45.ECFHttpClientFactory public class ECFHttpClientFactory implements IHttpClientFactory { ... private static final List<String> DEFAULT_PREFERRED_AUTH_SCHEMES = Arrays.asList(AuthSchemes.BASIC, AuthSchemes.DIGEST, AuthSchemes.NTLM); ... private static final Registry<AuthSchemeProvider> DEFAULT_AUTH_SCHEME_REGISTRY = RegistryBuilder.<AuthSchemeProvider> create().register(AuthSchemes.BASIC, new BasicSchemeFactory()).register(AuthSchemes.DIGEST, new DigestSchemeFactory()).register(AuthSchemes.NTLM, new NTLMSchemeFactory()).build(); ... } I miss the AuthSchemes.SPNEGO in the default auth schemes. So how can the default auth schemes be extended?
Created attachment 282904 [details] See Comment #9.
It looks like Negotiate is not implemented. Only the direct NTLM authentication was implemented by Yatta. Won't help me neither because or corporate proxy is limited to Kerberos for security reasons. see: https://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/providers/bundles/org.eclipse.ecf.provider.filetransfer.httpclient45/src/org/eclipse/ecf/internal/provider/filetransfer/httpclient45/HttpClientProxyCredentialProvider.java } else if ("negotiate".equalsIgnoreCase(authscope.getScheme())) { //$NON-NLS-1$ Trace.trace(Activator.PLUGIN_ID, "SPNEGO is not supported, if you can contribute support, please do so."); //$NON-NLS-1$ I wonder if anything from this old patch could be reused: https://bugs.eclipse.org/bugs/show_bug.cgi?id=408216
Looks like someone should really start to implement kerberos authentication now. Microsoft plans to remove NTLM support in Windows 11. https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-evolution-of-windows-authentication/ba-p/3926848
As you did trace the issue down to ECF, moving to that project. I didn't follow the project closely, probably you should also file the bug here: https://github.com/eclipse/ecf/ Note that (as always) for biggest chance to get the bug fixed, is to either provide the fix yourself or to pay somebody to fix it for you. You will need to find somebody with access to the right environment and right knowledge on the topic. @Ed wasn't there a request (long ago) from Microsoft on which topics they could help Eclipse?
https://github.com/eclipse/ecf/issues/73 "Replace ECF's filetransfer.httpclient5 with filetransfer.httpclientjava" https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/1389
(In reply to Christoph von Wittich from comment #14) > https://github.com/eclipse/ecf/issues/73 > > > "Replace ECF's filetransfer.httpclient5 with filetransfer.httpclientjava" > https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/ > 1389 Hi Christoph. I'm not clear on what you were trying to convey by adding the links to issue 73 and pr 1389. Just so it's clear to everyone: A proxy auth problem was found with the javahttpclient provider some weeks ago: https://github.com/eclipse/ecf/pull/78#pullrequestreview-1730572643 Because of this problem, the Eclipse platform project elected to include both the httpclient5 and the javahttpclient provider in the upcoming release 12-2023 I think it's called). A start-time property (see issue above) allows control of which provider is actually used. Also: I (ECF project lead) am not the author of the javahttpclient provider. That was/is Christoph Laubrich. It's probably going to require Christian's help in getting support for Kerberos into javahttpclient (at least for review and testing) so I've added @laubi onto https://github.com/eclipse/ecf/issues/73
