On Thu, 2011-04-21 at 21:07 +0000, Ron Jacobs wrote: > I must say that I hadn't wanted to say anything negative about that code > in my original post(s), but now that you've asked: > > The code now in your 4.1 distribution appears to be minimally (if at > all) unchanged from some code that I came across during a Google search > for better supporting NTLM within HttpClient way before I ever upgraded > to 4.x. I looked at that code in depth sometime last year and concluded > that there were just too many problems with it. > > Without going into technical details, which I have certainly mostly > forgotten by now anyway, that code seemed to have been written by > reverse engineering and guessing about NTLM some time before Microsoft > (finally) publicly released the NTLM specification. It may have worked > at one time for some specific combination of Windows parameters and > options but it was too far away from working for the general cases that > I needed. You see, unlike many NTLM client-side users that are just > trying to authenticate against a specific Windows server, I need to work > with just about any combo of Windows OS versions, service packs, > registry settings, installed apps, etc. >
This sounds quite unsettling. The NTLM engine used by HttpClient by default was contributed by the Lucene connector framework project as one big code drop. Since the code came from another ASF project I simply assumed it was clean and Lucene folks had done their due diligence. I am less concerned about quality of that code, but I am unpleasantly surprised that the implementation might have been based on an exiting piece of code developed through reverse engineering rather than based on the published specification. The main problem is that HttpClient may now have a large body of code that was originally published under uncertain / unclear licensing terms or under license incompatible with ASLv2. Is there any chance you could dig out a reference to what you believe is the original implementation? > So I abandoned that effort and when I recognized the same code inside > HttpClient, I was not hopeful. It was as I was looking for alternatives > that I asked the questions that you answered for me last month leading > me straight to this approach that is working great for us today. > > Seems to me that there is still no "open source" solution that is ready > to drop into the HttpClient distribution. I believe that the correct > approach is indeed JCIFS and that your restoring and updating the web > page is the best solution. If I were "forced" to write some NTLM code > without licensing issues for HttpClient it would end up looking much > too uncomfortably close to JCIFS. > I reckon no other group of people outside Microsoft know Microsoft network protocols better than Samba folks. I am sure that their NTLM implementation is solid and more comprehensive. I wish we could simply use it instead of having to maintain our own implementation. The problem is JCIFS is licensed under LGPL which makes its licensing terms incompatible with non-viral licenses such as ASLv2. As long as you are using JCIFS for your own needs or for an internal system in your company you are all fine. However, if you plan to distribute your application as a commercial product, LGPL becomes an issue and a legal liability. > I truly hope that I have offended no one. > No, really not. You helped a great deal. The NTLM guide has been restored and updated based on your input. Please review: http://svn.apache.org/viewvc?rev=1095921&view=rev http://svn.apache.org/viewvc/httpcomponents/httpclient/trunk/src/site/apt/ntlm.apt?view=markup Cheers Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
