Re: [aether-users] Versioning fun with Aether milestones

[Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>]

Benjamin Bentmann wrote:
> Andreas Sewe wrote:
>> no quite, no. Aether starts an NTLM handshake (sends NEGOTIATE, receives
>> CHALLENGE) but then fails to complete it (doesn't send the final AUTH).
>> But I am fairly confident that I can get this either working or send you
>> a detailed bug report. ;-)
> 
> The challenge-response handling upon auth is implemented by the HTTP
> lib. So if you can, would be worth to try a request using Apache
> HttpClient directly, to see whether Aether actually is involved in this.

OK, here are my findings so far. I hope you find them interesting.

Taking the bare-bones proxy authentication example [1] for the
HttpComponents website I was able to properly do Basic and Digest
authentication, but not NTLM authentication.

Now, this is against Squid 3.4.4 with its ntlm_fake_auth authentication
helper, which only does the handshake, doesn't actually check the
credentials. The helper may or may not implement the NTLM "spec"
correctly, but it is the simplest test setup I could piece together.

Interestingly, following the guidance on the HttpComponents website on
how to use Samba JCIFS as an alternative NTLM engine [2], I was able to
complete handshake and authentication using the provided
ClientProxyAuthentication example. Not sure whether this indicates a
problem with the HttpComponents NLTM engine or with Squid's
ntlm_fake_auth, though. I guess I'll have to seen the HttpComponents
some Wireshark captures so that they can figure that out.

That being said, *if* one would like to use this alternative engine with
Aether, the way to go is IMHO to write variants of
HttpTransporterFactory and HttpTransporter.

Unfortunately, HttpTransporterFactory is final (why?), so you can't just
overwrite its newInstance method, but fortunately it's not too much code
to copy and paste.

Now, all one would need to do with HttpTransporter is to sneak in a
single line [2]:

> httpclient.getAuthSchemes().register("ntlm", new NTLMSchemeFactory());

Alas, aether-transport-http's HttpTransport is extremely difficult to
extend. Would it be possible to restructure HttpTransporter such that
one can supply a different(ly configured) HttpClient?

The new my-transport-http bundle would then depend on
aether-transport-http and some bundled form of JCIFS, which fortunately
does exist already [3], albeit not in Orbit.

Best wishes,

Andreas

[1]
<https://hc.apache.org/httpcomponents-client-4.2.x/httpclient/examples/org/apache/http/examples/client/ClientProxyAuthentication.java>
[2] <https://hc.apache.org/httpcomponents-client-4.2.x/ntlm.html>
[3]
<http://search.maven.org/#search|ga|1|a%3A%22org.apache.servicemix.bundles.jcifs%22>

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940