On Sat, 2014-05-31 at 14:41 -0700, Nitin Handa wrote:
> Thanks Oleg. I can't simply use http client's ntlm stuff due to lots of other 
> complications. That's why I said in my original mail that I want to only use 
> httpclient connection reuse functionality as mentioned in the link I pasted 
> earlier.
> 
> I only want to make sure that after ntlm authentication, connection is used 
> only by same user..

Actually, HttpClient takes care of that out of the box.

> Is it possible somehow? What if I cache httpclient object per user? Or cache 
> http context per user? Will this help? If connection is held in http context 
> then using same context every time for that user should give me connection of 
> that user, is that correct?
> 
> Nitin
> 

I still do not quite see why you could not just use a custom AuthScheme.
But one can always drop to HttpCore level and build their own HTTP
client to suit their specific needs. 

http://svn.apache.org/repos/asf/httpcomponents/httpcore/branches/4.3.x/httpcore/src/examples/org/apache/http/examples/ElementalPoolingHttpGet.java

One could also create a custom connection pool and use a custom route
representation that includes user identity in the route definition and
ensures that only the same user could ever re-use a persistent
connection created with a particular user identity.

http://svn.apache.org/repos/asf/httpcomponents/httpcore/branches/4.3.x/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java

Hope this helps

Oleg


> > On May 31, 2014, at 10:44 AM, Oleg Kalnichevski <[email protected]> wrote:
> > 
> >> On Sat, 2014-05-31 at 10:12 -0700, Nitin Handa wrote:
> >> I looked at NTLMEngine interface, that's not going to help because I don't 
> >> have password , I have hashed password and that's the basic reason why I 
> >> can't use ntcredential, etc provided by httpclient.
> >> 
> >> Thanks 
> >> Nitin
> > 
> > Have a look at this
> > 
> > http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient-win/src/main/java/org/apache/http/impl/auth/win/
> > 
> > Oleg
> > 
> >>> On May 31, 2014, at 9:36 AM, Nitin Handa <[email protected]> wrote:
> >>> 
> >>> Can you please explain how will implementing NTLMEngine help in my use 
> >>> case?
> >>> 
> >>> Thanks,
> >>> Nitin
> >>> 
> >>>>> On May 31, 2014, at 8:34 AM, Oleg Kalnichevski <[email protected]> wrote:
> >>>>> 
> >>>>> On Fri, 2014-05-30 at 15:57 -0700, Nitin Handa wrote:
> >>>>> I want do NTLM authentication and also want to cache connection for 
> >>>>> future requests by same user. Since NTLM is connection based so we cant 
> >>>>> use same connection for different users.
> >>>>> 
> >>>>> I looked at this link which exactly describes my requirement:
> >>>>> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html#d5e715
> >>>>> 
> >>>>> Only caveat is that I don't want to use httpclient for NTLM 
> >>>>> authentication because i want to manually create Type1 and Type3 
> >>>>> messages and stick into http headers. But i want to use connection 
> >>>>> persistence feature described in above link to make sure that 
> >>>>> connection 
> >>>>> is not used by any other user.
> >>>>> 
> >>>>> So I am thinking that I can cache HttpClientContext object per session 
> >>>>> id (represents a user) and then use to for outbound calls. Do you think 
> >>>>> is viable and appropriate solution? if not then please provide 
> >>>>> recommendations.
> >>>> 
> >>>> If all you want is to manually generate Type1 and Type3 NTLM messages
> >>>> why would not you just implement a custom NTLMEngine or AuthScheme?
> >>>> 
> >>>> Oleg 
> >>>> 
> >>>> 
> >>>> 
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [email protected]
> >>>> For additional commands, e-mail: [email protected]
> >>> 
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [email protected]
> >>> For additional commands, e-mail: [email protected]
> >> 
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
> >> For additional commands, e-mail: [email protected]
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to