On 11/16/2012 10:20 AM, Max Rydahl Andersen wrote:
> The possible solutions I see are:
> 1) improve and contribute to the default NetAuthenticator in org.eclipse.ui. Problem
is that there's still no guarantee 3rd party plugins dont override this (improved)
Authenticator.
> 2) Switch to http client.
>
> WDYT?
with #2 you still need to do the same as what is done for #1 anyway ? i.e. read the right
settings.
yes for sure, we would have to read the proxy settings and set them to
the apache http client. This would simply allow us to avoid being
disturbed by any Authenticator hack there may be with the plugins
installed to Eclipse.
I think we should raise this issue on eclipse-platform mailing list and see if anyone see
a way out of this.
Yes, I basically agree on this, we should try to improve the platform,
not trying to not get disturbed. But facing the amount of hacks that
already out there, this wont be easy.
/max
>> p.s. in any case I'll say such move to apache should be done *after* GA
(experiemnt with it in a branch on your repo maybe?)
> yes, sure, no doubt.
>
>> /max
>>
>> On 08 Nov 2012, at 09:54, André Dietisheim <adietish(a)redhat.com> wrote:
>>
>>> On 11/08/2012 09:07 AM, Max Rydahl Andersen wrote:
>>>>>> The Apache HttpClient doesn't support NTLMv2 authentication.
>>>>>>
>>>>> According to this
http://hc.apache.org/httpcomponents-client-ga/ntlm.html
>>>>> it supports NTLMv2 in v4.1 and up.
>>>>>
>>>> no it doesn't - it requires using the LGPL library named JCIFS thus
that page is a possible example on how to configure it.
>>> The text says something different. It says that Apache HttpClient supports it
out-of-the-box, without JCIFS: " 4.1 supports NTLMv1 and NTLMv2 authentication
protocols out of the box using a custom authentication engine". It says that the
out-of-the-box engine is not very mature and has issue and that you can use JCIFS (LGPL)
instead of the default engine. JCIFS was not bundled because it's LGPL and they're
working towards solving the legal hurdles of bundling it.
>>>
>>>> /max
>>>>
>>>>
>>>>>> Snjeza
>>>>>>
>>>>>>
>>>>>>>> Snjeza
>>>>>>>>
>>>>>>>> On 11/7/2012 4:40 PM, André Dietisheim wrote:
>>>>>>>>
>>>>>>>>> Hi Snjezana
>>>>>>>>>
>>>>>>>>> good point!
>>>>>>>>> I already found out about this when looking at
different Eclipse plugins. EGit does it, Scout and apparently ECF, too. Quite a mess to be
honest: A bad API in the jdk UrlConnection, a poor implementation in org.eclipse.ui and
here we are: plenty of plugins overriding the Authenticator with unpredictable results.
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>> On 11/07/2012 04:21 PM, Snjezana Peco wrote:
>>>>>>>>>
>>>>>>>>>> I think you can disable it by setting your own
authenticator.
>>>>>>>>>> You can check how ECF sets its authenticator
using the
org.eclipse.ecf.provider.filetransfer.retrieve.UrlConnectionRetrieveFileTransfer.UrlConnectionAuthenticator
class and the Authenticator.setDefault method.
>>>>>>>>>>
>>>>>>>>>> Snjeza
>>>>>>>>>>
>>>>>>>>>> On 11/6/2012 3:12 PM, André Dietisheim wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> In OpenShift tooling I have a dialog that
allows you to create/edit connections to OpenShift. Behind the scenes I'm using
HttpUrlConnection to talk to the OpenShift REST service. If I provide invalid
user-credentials Eclipse pops up a dialog for the user to provide username and password on
top of my dialog.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
https://issues.jboss.org/browse/JBIDE-12999
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It turns out that Eclipse is registering
it's very own Authenticator in HttpUrlConnection which is invoking the Eclipse
credentials dialog if the Http response is 401.
>>>>>>>>>>> Does anybody know how to disable this in
Eclipse? I'm pretty stuck, I'd appreciate any input.
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>> jbosstools-dev mailing list
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> jbosstools-dev(a)lists.jboss.org
>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> jbosstools-dev mailing list
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> jbosstools-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>>> _______________________________________________
>>>>>>> jbosstools-dev mailing list
>>>>>>>
>>>>>>>
>>>>>>> jbosstools-dev(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>> _______________________________________________
>>>>>> jbosstools-dev mailing list
>>>>>>
>>>>>>
>>>>>> jbosstools-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>> _______________________________________________
>>>>> jbosstools-dev mailing list
>>>>>
>>>>> jbosstools-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev