| Summary: | jetty client cannot work with NTLM authentication | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | Shooray <shooray> | ||||
| Component: | client | Assignee: | Project Inbox <jetty-inbox> | ||||
| Status: | CLOSED MOVED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | carey, gregw, jesse.mcconnell, jetty-inbox, mgorovoy, michael.hawkshaw, pascal, yairogen | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 7.1.x | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Shooray
Greetings, NTLM authentication is connection-based, but Jetty HTTP Client is not aware of that, so this is likely the reason you are having problems. It is possible however to implement NTLM authentication in Jetty HTTP Client by detecting it in a custom listener and delegating the transport to the java.net.UrlConnection that supports NTLM authentication in Java 6. However, you are going to loose Jetty HTTP Client's asynchronous request handling as a result. Thanks, Michael *** This bug has been marked as a duplicate of bug 289669 *** Created attachment 176746 [details] This is a suggested implementation with jetty-client NTLM Authentication. This is a suggested implementation with jetty-client NTLM Authentication. NTLMAuthenticationTest.java is the test main program with JUnit4. Steps to Reproduce: 1. prepare a NTLM authentication needed web server, in my case, it is http://192.168.10.156/ntlm/index.asp, you should modify it. 2. replace the org.eclipse.....xxx.java files in jetty-client project 3. add jcifs-1.3.14.jar and JUnit4 jars to classpath, you can get jcifs from http://jcifs.samba.org/src/ 4. compile and run. it will work properly I wish jetty become better and better. Thanks for your efforts. Lion Sooray / shooray@gmail.com / 2010-8-17 Hi Michael:
You said right, I've also found detail about NTLM:
http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication
"3. ......From this point forward, the connection is kept open; closing the connection requires reauthentication of subsequent requests. This implies that the server and client must support persistent connections..."
And it was proved by sniffer tools.
However, it's a pity to hear you don't intend to implement NTLM Authentication in this jetty release. You said "loose Jetty HTTP Client's asynchronous request handling as a
result", I think that is not the truth. I've submited a suggested implementation with jetty-client NTLM Authentication for jetty project. Of cource, I'll use it in a production environment.
By the way, I suggest that you should put Realm(or RealmResolver) into exchange, not in HttpClient. So proxy can handle different request with different Principal/Credentials.
I wish jetty become better and better. Thanks for your efforts.
sadly jcifs is lgpl and as such there is no way we could take this patch...even if we were at apache I doubt we could take the patch since LGPL is basically off limits in most scenarios http://jcifs.samba.org/ pity its not a friendly license, if it had been we would have used it a long time ago the best bet is still banking on what support the jvm gives which is intermittent and dependent on the jvm and host operating system...we have had jetty client working with ntlm on linux, mac and windos jvm's using the mechanism that michael mentioned cheers jesse oh, but I applaud the effort! :) Hi jesse:
Thanks for your explanation about license and praise. I'm glad to have ability to contribute my efforts for you.
I don't think jcifs is the problem. Because I only use jcifs to make or parse type1,2,3 message. Moreover, NTLM protocol is open, anybody can implement it. I can rewrite it, or maybe Eclipse Communication Framework Project has finished it.
I've reopened this, so the effort does not get wasted. We can monitor the situation and if a license suitable jcifs replacement becomes available then we can move. We could also consider doing something in the codehaus release. *** Bug 289669 has been marked as a duplicate of this bug. *** There are several other NTLM authentication libraries, e.g. Waffle (http://waffle.codeplex.com/), http://www.luigidragone.com/networking/ntlm.html, etc. However all of them are LGPL licensed. nothing has really changed on this, its an enhancement and currently hands are tied regarding this due to IP issues...should that situation change I'll take it and resolve it once and for all I used jetty to implement a reverse proxy last year. More bugs had been found and be resolved temporarily by myself, such as url encoding, etc. For work with NTLM, I have to use jetty work in bio not nio. however, in bio, jetty worker thread will auto increment until the thread pool be exhausted. I have to write a shell script to monitor the proxy, if jetty proxy cannot work, restart it automatically. It's a headache. However, I am not responsible for that product now. If jetty team need my help, I'm still very happy to contribute something. Good luck jetty! It looks like Waffle is now using the Eclipse Public License: https://github.com/dblock/waffle/blob/master/LICENSE Does this make it useable for client authentication? score! that is good news first step is to get a CQ opened to use the library and then to get it into orbit I'll try and get that process started next week nice catch! update, until waffle is published in maven central I don't think we'll bother with getting the CQ through for this...it had moved to github and is EPL which is nice Looks like Waffle is now available in Maven Central: https://oss.sonatype.org/content/repositories/releases/com/github/dblock/waffle/ |