3:52 a.m.
On 11/08/2012 10:21 AM, Max Rydahl Andersen wrote:
whoops - my brain been primed to always read their client does not
support NTLM :)
but still - without integration into the eclipse proxy setup/preferences this is not
useful.
question is if that can be done nicely ?
Yes I think so. I'm not aware of the http client impl in details, but I
would expect them to have a very similar way to provide credentials.
Assuming this is true, we'd only have to look the preferences up. I can
dig into http client and verify my assumptions.
Just to make sure we understand each other right: I'm not suggesting
that we should switch. I'm only trying to figure out how to improve the
current situation in Eclipse which is pretty much a complete mess:
default impl in org.eclipse.ui is very poor, plenty of plugins simply
override it with different replacements.
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?
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