You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Pankaj Arora <PA...@castiron.com> on 2007/05/18 05:06:31 UTC
FW: HttpClient authentication problem.
________________________________
From: Pankaj Arora
Sent: Thursday, May 17, 2007 4:24 PM
To: 'httpcomponents-dev-info@jakarta.apache.org';
'httpcomponents-dev-faq@jakarta.apache.org'
Subject: HttpClient authentication problem.
Hi,
I am using Http Client to authenticate to IIS web Server for doing NTLM
authentication. Here's the description of sample codes I am using:
Program1 :: This code create 2 state,method,host configuration and use a
single instance of httpClient to execute method. Please not that in
first go I give the correct credentials for NTLM authentication and in
the second go I give the wrong credentials. In the response I observe
that I get http code 200 and in second go I don't even see
authentication happening when data is captured over ethereal.
Program2:: This code also create 2 state,method,host configuration but
use separate instance of httpClient to execute method. Please not that
in first go I give the correct credentials for NTLM authentication and
in the second go I give the wrong credentials. In the response I observe
that I get http code 200 and in second go I get response code as 401.
The problem is I want to use single instance of HttpClient and also want
that session info is not maintained over the requests. Simply speaking I
want behavior 2 to happen when their is single instance of HttpClient.
Is there a way to do this?
Code and response received from server for reference.
Program1:
________________________________________________________________________
___________________________________________________________
// Create an instance of HttpClient.
HttpClient client1 = new HttpClient();
HttpMethod _method1 = new GetMethod(url);
HttpState _httpState1 = new HttpState();
HostConfiguration hostConfig1 = new HostConfiguration();
UsernamePasswordCredentials credentials1;
credentials1 = new
NTCredentials("administrator","password","host","domain");
AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
_httpState1.setCredentials(authScope1,credentials1);
hostConfig1.setHost("host"port);
try {
// Execute the method.
int statusCode =
client1.executeMethod(hostConfig1,_method1,_httpState1);
System.out.println("Status code :" + statusCode);
if (statusCode != HttpStatus.SC_OK) {
System.err.println("Method failed: " + _method1.getStatusLine()
+ "StatusCode:" + statusCode);
}
// Read the response body.
byte[] responseBody = _method1.getResponseBody();
Header[] responseHeaders = _method1.getResponseHeaders();
// Header header;
System.out.println("----------------------------------------------------
-----------------------------------");
for( Header header : responseHeaders){
System.out.println("Headers is " + header.getName() + "and the value
is :" + header.getValue());
}
HttpMethod _method2 = new GetMethod(url);
HttpState _httpState2 = new HttpState();
HostConfiguration hostConfig2 = new HostConfiguration();
UsernamePasswordCredentials credentials2;
credentials2 = new NTCredentials("administrator","wrong
password","host","domain");
AuthScope authScope2 = new AuthScope("host",port,"host","domain");
_httpState2.setCredentials(authScope2,credentials2);
hostConfig2.setHost("host",port);
_httpState2.setCredentials(authScope2,credentials2);
statusCode =
client1.executeMethod(hostConfig2,_method2,_httpState2);
System.out.println("Status code :" + statusCode);
if (statusCode != HttpStatus.SC_OK) {
System.err.println("Method failed: " + _method2.getStatusLine()
+ "StatusCode:" + statusCode);
}
// Read the response body.
responseBody = _method2.getResponseBody();
responseHeaders = _method2.getResponseHeaders();
// Header header;
System.out.println("----------------------------------------------------
-----------------------------------");
for( Header header : responseHeaders){
System.out.println("Headers is " + header.getName() + "and the value
is :" + header.getValue());
}
________________________________________________________________________
__________________________________________________________________
Response 1:
________________________________________________________________________
___________________________________________________________________
May 17, 2007 2:40:17 AM
org.apache.commons.httpclient.auth.AuthChallengeProcessor
selectAuthScheme
INFO: ntlm authentication scheme selected
Status code :200
------------------------------------------------------------------------
---------------
Headers is Content-Lengthand the value is :51
Headers is Content-Typeand the value is :text/html
Headers is Last-Modifiedand the value is :Sat, 14 Apr 2007 08:44:30 GMT
Headers is Accept-Rangesand the value is :bytes
Headers is ETagand the value is :"5cc42b1e717ec71:11d9"
Headers is Serverand the value is :Microsoft-IIS/6.0
Headers is Dateand the value is :Thu, 17 May 2007 09:30:53 GMT
Status code :200
------------------------------------------------------------------------
---------------
Headers is Content-Lengthand the value is :51
Headers is Content-Typeand the value is :text/html
Headers is Last-Modifiedand the value is :Sat, 14 Apr 2007 08:44:30 GMT
Headers is Accept-Rangesand the value is :bytes
Headers is ETagand the value is :"5cc42b1e717ec71:11d9"
Headers is Serverand the value is :Microsoft-IIS/6.0
Headers is Dateand the value is :Thu, 17 May 2007 09:30:53 GMT
________________________________________________________________________
____________________________________________________________
Program2:
________________________________________________________________________
______________________________________________________________
// Create an instance of HttpClient.
HttpClient client1 = new HttpClient();
HttpMethod _method1 = new GetMethod(url);
HttpState _httpState1 = new HttpState();
HostConfiguration hostConfig1 = new HostConfiguration();
UsernamePasswordCredentials credentials1;
credentials1 = new
NTCredentials("administrator","password","host","domain");
AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
_httpState1.setCredentials(authScope1,credentials1);
hostConfig1.setHost("host"port);
try {
// Execute the method.
int statusCode =
client1.executeMethod(hostConfig1,_method1,_httpState1);
System.out.println("Status code :" + statusCode);
if (statusCode != HttpStatus.SC_OK) {
System.err.println("Method failed: " + _method1.getStatusLine()
+ "StatusCode:" + statusCode);
}
// Read the response body.
byte[] responseBody = _method1.getResponseBody();
Header[] responseHeaders = _method1.getResponseHeaders();
// Header header;
System.out.println("----------------------------------------------------
-----------------------------------");
for( Header header : responseHeaders){
System.out.println("Headers is " + header.getName() + "and the value
is :" + header.getValue());
}
HttpClient client2 = new HttpClient();
HttpMethod _method2 = new GetMethod(url);
HttpState _httpState2 = new HttpState();
HostConfiguration hostConfig2 = new HostConfiguration();
UsernamePasswordCredentials credentials2;
credentials2 = new NTCredentials("administrator","wrong
password","host","domain");
AuthScope authScope2 = new AuthScope("host",port,"host","domain");
_httpState2.setCredentials(authScope2,credentials2);
hostConfig2.setHost("host",port);
_httpState2.setCredentials(authScope2,credentials2);
statusCode =
client2.executeMethod(hostConfig2,_method2,_httpState2);
System.out.println("Status code :" + statusCode);
if (statusCode != HttpStatus.SC_OK) {
System.err.println("Method failed: " + _method2.getStatusLine()
+ "StatusCode:" + statusCode);
}
// Read the response body.
responseBody = _method2.getResponseBody();
responseHeaders = _method2.getResponseHeaders();
// Header header;
System.out.println("----------------------------------------------------
-----------------------------------");
for( Header header : responseHeaders){
System.out.println("Headers is " + header.getName() + "and the value
is :" + header.getValue());
}
________________________________________________________________________
__________________________________________________________________
Response 2:
________________________________________________________________________
___________________________________________________________________
May 17, 2007 3:43:07 AM
org.apache.commons.httpclient.auth.AuthChallengeProcessor
selectAuthScheme
INFO: ntlm authentication scheme selected
Status code :200
------------------------------------------------------------------------
---------------
Headers is Content-Lengthand the value is :51
Headers is Content-Typeand the value is :text/html
Headers is Last-Modifiedand the value is :Sat, 14 Apr 2007 08:44:30 GMT
Headers is Accept-Rangesand the value is :bytes
Headers is ETagand the value is :"5cc42b1e717ec71:11e1"
Headers is Serverand the value is :Microsoft-IIS/6.0
Headers is Dateand the value is :Thu, 17 May 2007 10:33:42 GMT
May 17, 2007 3:43:08 AM
org.apache.commons.httpclient.auth.AuthChallengeProcessor
selectAuthScheme
INFO: ntlm authentication scheme selected
May 17, 2007 3:43:08 AM org.apache.commons.httpclient.HttpMethodDirector
processWWWAuthChallenge
INFO: Failure authenticating with NTLM <any realm>@vm3-ntlm-01:8589
Status code :401
Method failed: HTTP/1.1 401 UnauthorizedStatusCode:401
------------------------------------------------------------------------
---------------
Headers is Content-Lengthand the value is :1539
Headers is Content-Typeand the value is :text/html
Headers is Serverand the value is :Microsoft-IIS/6.0
Headers is WWW-Authenticateand the value is :Negotiate
Headers is WWW-Authenticateand the value is :NTLM
Headers is Dateand the value is :Thu, 17 May 2007 10:33:42 GMT
________________________________________________________________________
_______________________________________________________________
Re: FW: HttpClient authentication problem.
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-05-18 at 11:27 +0200, Ortwin Glück wrote:
> Pankaj,
>
> With the multithreaded conn manager you can try and set the
> "Connection: close" header with each request. This should effectively
> disable keep-alive connections. If that doesn't work well with your
> server, it's probably best to implement your own connection manager that
> is thread-safe but still closes connections when they are returned to
> the "pool".
>
> Oleg, Roland, do you see other possibilities?
>
I am afraid not. HttpClient 3.x treats all connections as stateless and
does not take into account stateful authentication schemes such as NTLM
or certificate based user SSL authentication. Dropping connections upon
release is the only way to ensure they do not get re-used by some other
user.
Oleg
> Ortwin
>
> Pankaj Arora wrote:
> > Hi Ortwin,
> > There is a problem:
> >
> > In real scenario- I am using a design which looks something like this
> >
> > Single instance of HttpClient->Single Instance of MultithreadedConnectionManger.
> >
> > Now these are used by multiple threads to acquire instance of client(which is created using a single instance of Multithreaded connection manager) and calls something like
> >
> > getSingletonInstance().executeMethod(hostconfig,method,state);
> >
> > Where
> >
> > HttpClient getSingletonInstance(){
> > //This is implmented as singleton and returns
> > new HttpClient(new MultithreadedConnectionManager());
> > }
> >
> > Then each request is executed. Now until I undeploy(clean up) the whole application the second thread using the same instance of HttpClient do not authenticate for the second request.
> >
> > I understand that if I were using the SimpleHttpConnectionMAnger I could have used the new HttpClient(new SimpleHttpConnectionManager(true)); as suggested by you to close the connection and would have worked for me. I have tried and it do work for me.
> >
> >
> > But in this case while using multithreaded connection manager I don't know what to do.
> >
> > Also please note that I am using the stable version 3.0.1 which doesn't have API call like you have just suggested.
> > Though I have tried your suggestion on 3.1rc1 and it worked well.
> >
> > Will appreciate your thoughts on this.
> >
> > Thanks,
> > Pankaj Arora
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Ortwin Glück [mailto:odi@odi.ch]
> > Sent: Friday, May 18, 2007 1:44 PM
> > To: HttpComponents Project
> > Subject: Re: FW: HttpClient authentication problem.
> >
> > Pankaj,
> >
> > BASIC auth authenticates only a request.
> > NTLM auth however authenticates a whole connection!
> >
> > So if the connection is reused no further authentication will be requested. That's what you are seeing. If you want to authenticate each request, you must make sure that the connection is closed after the request. You can achieve this by disabling connection pooling:
> >
> > new HttpClient(new SimpleHttpConnectionManager(true));
> >
> > Cheers
> >
> > Ortwin
> >
> > Pankaj Arora wrote:
> >>
> >>
> >> ________________________________
> >>
> >> From: Pankaj Arora
> >> Sent: Thursday, May 17, 2007 4:24 PM
> >> To: 'httpcomponents-dev-info@jakarta.apache.org';
> >> 'httpcomponents-dev-faq@jakarta.apache.org'
> >> Subject: HttpClient authentication problem.
> >>
> >>
> >> Hi,
> >> I am using Http Client to authenticate to IIS web Server for doing
> >> NTLM authentication. Here's the description of sample codes I am using:
> >>
> >>
> >> Program1 :: This code create 2 state,method,host configuration and use
> >> a single instance of httpClient to execute method. Please not that in
> >> first go I give the correct credentials for NTLM authentication and in
> >> the second go I give the wrong credentials. In the response I observe
> >> that I get http code 200 and in second go I don't even see
> >> authentication happening when data is captured over ethereal.
> >>
> >> Program2:: This code also create 2 state,method,host configuration but
> >> use separate instance of httpClient to execute method. Please not that
> >> in first go I give the correct credentials for NTLM authentication and
> >> in the second go I give the wrong credentials. In the response I
> >> observe that I get http code 200 and in second go I get response code as 401.
> >>
> >> The problem is I want to use single instance of HttpClient and also
> >> want that session info is not maintained over the requests. Simply
> >> speaking I want behavior 2 to happen when their is single instance of HttpClient.
> >> Is there a way to do this?
> >>
> >>
> >>
> >> Code and response received from server for reference.
> >>
> >> Program1:
> >> ______________________________________________________________________
> >> __ ___________________________________________________________
> >> // Create an instance of HttpClient.
> >> HttpClient client1 = new HttpClient();
> >> HttpMethod _method1 = new GetMethod(url);
> >> HttpState _httpState1 = new HttpState();
> >> HostConfiguration hostConfig1 = new HostConfiguration();
> >> UsernamePasswordCredentials credentials1;
> >> credentials1 = new
> >> NTCredentials("administrator","password","host","domain");
> >>
> >> AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
> >>
> >> _httpState1.setCredentials(authScope1,credentials1);
> >> hostConfig1.setHost("host"port);
> >>
> >> try {
> >> // Execute the method.
> >> int statusCode =
> >> client1.executeMethod(hostConfig1,_method1,_httpState1);
> >>
> >> System.out.println("Status code :" + statusCode);
> >> if (statusCode != HttpStatus.SC_OK) {
> >> System.err.println("Method failed: " +
> >> _method1.getStatusLine()
> >> + "StatusCode:" + statusCode);
> >> }
> >>
> >> // Read the response body.
> >> byte[] responseBody = _method1.getResponseBody();
> >>
> >>
> >> Header[] responseHeaders = _method1.getResponseHeaders();
> >> // Header header;
> >>
> >> System.out.println("--------------------------------------------------
> >> -- -----------------------------------");
> >> for( Header header : responseHeaders){
> >> System.out.println("Headers is " + header.getName() + "and the
> >> value is :" + header.getValue());
> >> }
> >>
> >>
> >> HttpMethod _method2 = new GetMethod(url);
> >> HttpState _httpState2 = new HttpState();
> >> HostConfiguration hostConfig2 = new HostConfiguration();
> >> UsernamePasswordCredentials credentials2;
> >> credentials2 = new NTCredentials("administrator","wrong
> >> password","host","domain");
> >>
> >> AuthScope authScope2 = new AuthScope("host",port,"host","domain");
> >>
> >> _httpState2.setCredentials(authScope2,credentials2);
> >> hostConfig2.setHost("host",port);
> >> _httpState2.setCredentials(authScope2,credentials2);
> >> statusCode =
> >> client1.executeMethod(hostConfig2,_method2,_httpState2);
> >>
> >> System.out.println("Status code :" + statusCode);
> >> if (statusCode != HttpStatus.SC_OK) {
> >> System.err.println("Method failed: " +
> >> _method2.getStatusLine()
> >> + "StatusCode:" + statusCode);
> >> }
> >>
> >> // Read the response body.
> >> responseBody = _method2.getResponseBody();
> >> responseHeaders = _method2.getResponseHeaders();
> >> // Header header;
> >>
> >> System.out.println("--------------------------------------------------
> >> -- -----------------------------------");
> >> for( Header header : responseHeaders){
> >> System.out.println("Headers is " + header.getName() + "and the
> >> value is :" + header.getValue());
> >> }
> >> ______________________________________________________________________
> >> __ __________________________________________________________________
> >>
> >> Response 1:
> >> ______________________________________________________________________
> >> __ ___________________________________________________________________
> >> May 17, 2007 2:40:17 AM
> >> org.apache.commons.httpclient.auth.AuthChallengeProcessor
> >> selectAuthScheme
> >> INFO: ntlm authentication scheme selected Status code :200
> >> ----------------------------------------------------------------------
> >> --
> >> ---------------
> >> Headers is Content-Lengthand the value is :51 Headers is
> >> Content-Typeand the value is :text/html Headers is Last-Modifiedand
> >> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
> >> Accept-Rangesand the value is :bytes Headers is ETagand the value is
> >> :"5cc42b1e717ec71:11d9"
> >> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
> >> Dateand the value is :Thu, 17 May 2007 09:30:53 GMT Status code :200
> >> ----------------------------------------------------------------------
> >> --
> >> ---------------
> >> Headers is Content-Lengthand the value is :51 Headers is
> >> Content-Typeand the value is :text/html Headers is Last-Modifiedand
> >> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
> >> Accept-Rangesand the value is :bytes Headers is ETagand the value is
> >> :"5cc42b1e717ec71:11d9"
> >> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
> >> Dateand the value is :Thu, 17 May 2007 09:30:53 GMT
> >> ______________________________________________________________________
> >> __ ____________________________________________________________
> >>
> >>
> >> Program2:
> >> ______________________________________________________________________
> >> __ ______________________________________________________________
> >>
> >> // Create an instance of HttpClient.
> >> HttpClient client1 = new HttpClient();
> >> HttpMethod _method1 = new GetMethod(url);
> >> HttpState _httpState1 = new HttpState();
> >> HostConfiguration hostConfig1 = new HostConfiguration();
> >> UsernamePasswordCredentials credentials1;
> >> credentials1 = new
> >> NTCredentials("administrator","password","host","domain");
> >>
> >> AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
> >>
> >> _httpState1.setCredentials(authScope1,credentials1);
> >> hostConfig1.setHost("host"port);
> >>
> >> try {
> >> // Execute the method.
> >> int statusCode =
> >> client1.executeMethod(hostConfig1,_method1,_httpState1);
> >>
> >> System.out.println("Status code :" + statusCode);
> >> if (statusCode != HttpStatus.SC_OK) {
> >> System.err.println("Method failed: " +
> >> _method1.getStatusLine()
> >> + "StatusCode:" + statusCode);
> >> }
> >>
> >> // Read the response body.
> >> byte[] responseBody = _method1.getResponseBody();
> >>
> >>
> >> Header[] responseHeaders = _method1.getResponseHeaders();
> >> // Header header;
> >>
> >> System.out.println("--------------------------------------------------
> >> -- -----------------------------------");
> >> for( Header header : responseHeaders){
> >> System.out.println("Headers is " + header.getName() + "and the
> >> value is :" + header.getValue());
> >> }
> >>
> >> HttpClient client2 = new HttpClient();
> >> HttpMethod _method2 = new GetMethod(url);
> >> HttpState _httpState2 = new HttpState();
> >> HostConfiguration hostConfig2 = new HostConfiguration();
> >> UsernamePasswordCredentials credentials2;
> >> credentials2 = new NTCredentials("administrator","wrong
> >> password","host","domain");
> >>
> >> AuthScope authScope2 = new AuthScope("host",port,"host","domain");
> >>
> >> _httpState2.setCredentials(authScope2,credentials2);
> >> hostConfig2.setHost("host",port);
> >> _httpState2.setCredentials(authScope2,credentials2);
> >> statusCode =
> >> client2.executeMethod(hostConfig2,_method2,_httpState2);
> >>
> >> System.out.println("Status code :" + statusCode);
> >> if (statusCode != HttpStatus.SC_OK) {
> >> System.err.println("Method failed: " +
> >> _method2.getStatusLine()
> >> + "StatusCode:" + statusCode);
> >> }
> >>
> >> // Read the response body.
> >> responseBody = _method2.getResponseBody();
> >> responseHeaders = _method2.getResponseHeaders();
> >> // Header header;
> >>
> >> System.out.println("--------------------------------------------------
> >> -- -----------------------------------");
> >> for( Header header : responseHeaders){
> >> System.out.println("Headers is " + header.getName() + "and the
> >> value is :" + header.getValue());
> >> }
> >> ______________________________________________________________________
> >> __ __________________________________________________________________
> >>
> >> Response 2:
> >> ______________________________________________________________________
> >> __ ___________________________________________________________________
> >> May 17, 2007 3:43:07 AM
> >> org.apache.commons.httpclient.auth.AuthChallengeProcessor
> >> selectAuthScheme
> >> INFO: ntlm authentication scheme selected Status code :200
> >> ----------------------------------------------------------------------
> >> --
> >> ---------------
> >> Headers is Content-Lengthand the value is :51 Headers is
> >> Content-Typeand the value is :text/html Headers is Last-Modifiedand
> >> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
> >> Accept-Rangesand the value is :bytes Headers is ETagand the value is
> >> :"5cc42b1e717ec71:11e1"
> >> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
> >> Dateand the value is :Thu, 17 May 2007 10:33:42 GMT May 17, 2007
> >> 3:43:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor
> >> selectAuthScheme
> >> INFO: ntlm authentication scheme selected May 17, 2007 3:43:08 AM
> >> org.apache.commons.httpclient.HttpMethodDirector
> >> processWWWAuthChallenge
> >> INFO: Failure authenticating with NTLM <any realm>@vm3-ntlm-01:8589
> >> Status code :401 Method failed: HTTP/1.1 401
> >> UnauthorizedStatusCode:401
> >> ----------------------------------------------------------------------
> >> --
> >> ---------------
> >> Headers is Content-Lengthand the value is :1539 Headers is
> >> Content-Typeand the value is :text/html Headers is Serverand the value
> >> is :Microsoft-IIS/6.0 Headers is WWW-Authenticateand the value is
> >> :Negotiate Headers is WWW-Authenticateand the value is :NTLM Headers
> >> is Dateand the value is :Thu, 17 May 2007 10:33:42 GMT
> >> ______________________________________________________________________
> >> __ _______________________________________________________________
> >>
> >
> > --
> > [web] http://www.odi.ch/
> > [blog] http://www.odi.ch/weblog/
> > [pgp] key 0x81CF3416
> > finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: FW: HttpClient authentication problem.
Posted by Pankaj Arora <PA...@castiron.com>.
-----Original Message-----
From: Ortwin Glück [mailto:odi@odi.ch]
Sent: Friday, May 18, 2007 3:32 PM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj,
When always closing the connections it makes no sense to pool them. The MultithreadedConnectionManager is an overkill base class for this case, as it tries to do the exact oposite. Rather start a conn mgr from scratch. Look at the SimpleHttpConnectionManager for sample code.
getConnectionWithTimeout can just create a new connection every time.
public HttpConnection getConnectionWithTimeout(
HostConfiguration hostConfiguration, long timeout) {
HttpConnection httpConnection = new HttpConnection(hostConfiguration);
httpConnection.setHttpConnectionManager(this);
httpConnection.getParams().setDefaults(this.params);
return httpConnection;
}
and releaseConnection() can just close it:
public void releaseConnection(HttpConnection conn) {
if (conn != httpConnection) {
throw new IllegalStateException("Unexpected release of an unknown connection.");
}
httpConnection.close();
}
This connection manager can be completely stateless and thus unsynchronized.
Ortwin
Pankaj Arora wrote:
> But how to close connection while they are returned to pool.
> I completely missed this part. What to overload here?
>
> May be something like this ::
>
> Void releaseConnection(httpConnection connection){ connection.close();
> super.releaseConnection();
>
> }
> Right?
>
> Thanks,
> Pankaj Arora
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Oleg Kalnichevski <ol...@apache.org>.
Pankaj Arora wrote:
> Oleg,
> I contributed some code myself to make Kerberos work
> https://issues.apache.org/jira/browse/HTTPCLIENT-523
> I have no issues porting it. Issue is that now AuthPolicy does not
> support API to register any other auth scheme like it did before.
> http://hc.apache.org/httpcomponents-client/httpclient/apidocs/index.html
> in 4.0 b2.
> In 3.x -- http://hc.apache.org/httpclient-3.x/apidocs/index.html
> You gave an option to register another schema and that way at least let
> developers write their authenticate method for that scheme. Now that
> extensibility is lost.
>
No, it is not.
> Please correct me if I am wrong.
>
Please take a closer look at the AbstractHttpClient class and the
AuthSchemeRegistry interface.
http://hc.apache.org/httpcomponents-client/httpclient/apidocs/org/apache/http/impl/client/AbstractHttpClient.html#getAuthSchemes()
http://hc.apache.org/httpcomponents-client/httpclient/apidocs/org/apache/http/auth/AuthSchemeRegistry.html
Oleg
> Thanks,
> Pankaj Arora
> p.s: Will be more than happy to contribute in helping out with Kerberos
> and we are using Kerberos successfully in our product using Http Client.
>
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Saturday, January 24, 2009 4:06 AM
> To: HttpComponents Project
> Subject: Re: FW: HttpClient authentication problem.
>
> Pankaj Arora wrote:
>> Hi,
>> We in our product support Kerberos auth scheme and while using 3.x
> version of HttpClient we did that by registering Kerberos scheme with
> the AuthPolicy class.
>> In 4.x Api I see no way to register the schemes we might want to
> implement and support. It looks like other than Basic,Digest and NTLM we
> cannot support any other auth scheme.
>> Is that right?
>>
>
> Pankaj,
>
> SPNEGO scheme is also unsupported in HttpClient 3.x. There exists an
> unofficial implementation contributed by a third party developer who is
> no longer there to support it [1]. This is the reason why it was not
> included in HttpClient 4.0. There is simply no one around both capable
> and willing to support SPNEGO.
>
> Feel free to port it to the 4.0 API, if you have a need for it.
>
> Oleg
>
> [1]
> http://svn.apache.org/repos/asf/httpcomponents/oac.hc3x/trunk/src/contri
> b/org/apache/commons/httpclient/contrib/auth/
>
>
>
>
>> Thanks,
>> Pankaj Arora
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
RE: FW: HttpClient authentication problem.
Posted by Pankaj Arora <pa...@castiron.com>.
Oleg,
I contributed some code myself to make Kerberos work
https://issues.apache.org/jira/browse/HTTPCLIENT-523
I have no issues porting it. Issue is that now AuthPolicy does not
support API to register any other auth scheme like it did before.
http://hc.apache.org/httpcomponents-client/httpclient/apidocs/index.html
in 4.0 b2.
In 3.x -- http://hc.apache.org/httpclient-3.x/apidocs/index.html
You gave an option to register another schema and that way at least let
developers write their authenticate method for that scheme. Now that
extensibility is lost.
Please correct me if I am wrong.
Thanks,
Pankaj Arora
p.s: Will be more than happy to contribute in helping out with Kerberos
and we are using Kerberos successfully in our product using Http Client.
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Saturday, January 24, 2009 4:06 AM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj Arora wrote:
> Hi,
> We in our product support Kerberos auth scheme and while using 3.x
version of HttpClient we did that by registering Kerberos scheme with
the AuthPolicy class.
> In 4.x Api I see no way to register the schemes we might want to
implement and support. It looks like other than Basic,Digest and NTLM we
cannot support any other auth scheme.
>
> Is that right?
>
Pankaj,
SPNEGO scheme is also unsupported in HttpClient 3.x. There exists an
unofficial implementation contributed by a third party developer who is
no longer there to support it [1]. This is the reason why it was not
included in HttpClient 4.0. There is simply no one around both capable
and willing to support SPNEGO.
Feel free to port it to the 4.0 API, if you have a need for it.
Oleg
[1]
http://svn.apache.org/repos/asf/httpcomponents/oac.hc3x/trunk/src/contri
b/org/apache/commons/httpclient/contrib/auth/
> Thanks,
> Pankaj Arora
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: FW: HttpClient authentication problem.
Posted by Oleg Kalnichevski <ol...@apache.org>.
Pankaj Arora wrote:
> Hi,
> We in our product support Kerberos auth scheme and while using 3.x version of HttpClient we did that by registering Kerberos scheme with the AuthPolicy class.
> In 4.x Api I see no way to register the schemes we might want to implement and support. It looks like other than Basic,Digest and NTLM we cannot support any other auth scheme.
>
> Is that right?
>
Pankaj,
SPNEGO scheme is also unsupported in HttpClient 3.x. There exists an
unofficial implementation contributed by a third party developer who is
no longer there to support it [1]. This is the reason why it was not
included in HttpClient 4.0. There is simply no one around both capable
and willing to support SPNEGO.
Feel free to port it to the 4.0 API, if you have a need for it.
Oleg
[1]
http://svn.apache.org/repos/asf/httpcomponents/oac.hc3x/trunk/src/contrib/org/apache/commons/httpclient/contrib/auth/
> Thanks,
> Pankaj Arora
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
RE: FW: HttpClient authentication problem.
Posted by Pankaj Arora <pa...@castiron.com>.
Hi,
We in our product support Kerberos auth scheme and while using 3.x version of HttpClient we did that by registering Kerberos scheme with the AuthPolicy class.
In 4.x Api I see no way to register the schemes we might want to implement and support. It looks like other than Basic,Digest and NTLM we cannot support any other auth scheme.
Is that right?
Thanks,
Pankaj Arora
-----Original Message-----
From: Pankaj Arora [mailto:parora@castiron.com]
Sent: Friday, January 16, 2009 10:35 AM
To: HttpComponents Project
Subject: RE: FW: HttpClient authentication problem.
Hi Tushar,Oleg,
Can you please provide an OSGI bundle for httpcomponents-client-4.0-beta2-bin-with-dependencies.zip as you have for core and client separately?
Thanks,
Pankaj Arora
-----Original Message-----
From: Tushar Kapila [mailto:tushar.kapila.2@gmail.com]
Sent: Friday, January 16, 2009 9:18 AM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj
https://issues.apache.org/jira/browse/HTTPCORE-179
if you download the samples you can see a reference implementation and their
are 4 jars to be included in classpath from
http://www.apache.org/dist/httpcomponents/httpclient/binary/httpcomponents-client-4.0-beta2-bin-with-dependencies.zip
Oleg
I made a sample quick start guide - will need to edit it for reqiored jars
until the API, release file name patterns and locations stabalizes.
See it at http://wiki.apache.org/HttpComponents/QuickStart
Regards
Tushar Kapila
----- Original Message -----
From: "Pankaj Arora" <pa...@castiron.com>
To: "HttpComponents Project" <de...@hc.apache.org>
Sent: Friday, January 16, 2009 5:08 AM
Subject: RE: FW: HttpClient authentication problem.
Hi Oleg,
Thanks for your reply.
I have started porting the Api to 4.x and it looks like many of classes
namely org.apache.http.Header, org.apache.http.message.AbstractHttpMessage
etc are not part of the Http Components Client but are part of Http Core. So
to move to 4.x I need to have both Http Core libraries and Http Components
Client libraries?
Is that the case? Please verify.
Thanks,
Pankaj Arora
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Saturday, January 10, 2009 5:33 AM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj Arora wrote:
> Hi,
> I am using HttpClient 3.x till now. It looks like 4.x is completely
> overhauled and there are major API changes that happened. I thought
> solution to this problem lied in having authentication info available to
> connection managers so the stateful connection is not reused. I was
> looking at 4.x Api docs
> http://hc.apache.org/httpcomponents-client/httpclient/apidocs/index.html
> And I don't see any MultiThreaded Connection Manager.
http://hc.apache.org/httpcomponents-client/examples.html
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-client/src/examples/org/apache/http/examples/client/ClientMultiThreadedExecution.java
> In fact looks like everything has moved to org.apache.http.* packages from
> org.apache.commons.*.
> If that's the case,
Yes, this is the case, because 4.0 is a complete rewrite of the old code
line.
can you tell me if there is some guide that can tell me how I can make
my existing product compatible with 4.x release?
You need to port it to the new API.
> Second how the existing bug we are talking about can be resolved in new
> design.
>
HTTP connection managers in 4.0 are now aware that connections can be
stateful. They can take the connection state into consideration when
serving a request for a persistent connection. Standard connection
managers automatically take user identity into consideration when
managing NTLM authenticated connections.
Please make sure to read this, though
http://hc.apache.org/httpcomponents-client/ntlm.html
Oleg
> I am sorry as I am bit confused as I wasn't following 4.x development from
> scratch.
>
> Thanks,
> Pankaj Arora
>
> -----Original Message-----
> From: Pankaj Arora [mailto:parora@castiron.com]
> Sent: Tuesday, January 06, 2009 3:21 PM
> To: HttpComponents Project
> Subject: RE: FW: HttpClient authentication problem.
>
> Hi Odi and Roland,
> Was curious to know if this feature finally made to 4.0. Moreover when
> final 4.0 verison for commons is expected?
>
> Thanks,
> Pankaj Arora
>
>
> Hi Odi,
>
>> I would actually consider this a security issue in the connection
>> managers: It may hand out an already authenticated connection to an
>> unsuspecting client. We should add fields to HttpConnection that keep
>> track of the credentials for connection oriented AuthSchemes. So
>> connection managers can take this into account. Also the connection
>> managers lack a parameter in the getConnection methods that carries
>> authentication information for connection based auth schemes.
>
> It's on my list for 4.0, though it won't make it into client alpha1:
> http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign
> It's not urgent since we won't have NTLM support for a while.
>
> I don't think we can or should squeeze this into 3.x anymore.
>
> cheers,
> Roland
>
> -----Original Message-----
> From: Ortwin Glück [mailto:odi@odi.ch]
> Sent: Friday, May 18, 2007 5:41 AM
> To: HttpComponents Project
> Subject: Re: FW: HttpClient authentication problem.
>
> Pankaj,
>
> NTLM is designed to authenticate a connection. AFAIK it does not support
> a "logout" in the middle of a connection, nor does it support preemptive
> authentication. So the only way to force a new authentication is to
> close the connection. (e.g. try and clear the authentication to a mapped
> network drive in Windows. Probably the same issue there.)
>
> Thus it's not possible to share a connection between users when using
> NTLM auth. Yes, this may cause a performance hit if you were planning to
> share a connection between different users.
>
> You could tweak your connection manager to remember the authenticated
> user for each connection and try to find an already authenticated one or
> hand out a new one if you can't.
>
> I would actually consider this a security issue in the connection
> managers: It may hand out an already authenticated connection to an
> unsuspecting client. We should add fields to HttpConnection that keep
> track of the credentials for connection oriented AuthSchemes. So
> connection managers can take this into account. Also the connection
> managers lack a parameter in the getConnection methods that carries
> authentication information for connection based auth schemes.
>
> Ortwin
>
>
> Pankaj Arora wrote:
>> Thanks, That worked for me. Only thing that worries me is that
>> connections don't persist now. It might be a performance issue. Only
>> thing which I would like to know from you( as I am bit novice here)-
>> what is the right behavior, my client not authenticating second time
>> as connection is already authenticated or closing the connections to
>> force authentication repeatedly.
>>
>> Thanks, Pankaj Arora.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
RE: FW: HttpClient authentication problem.
Posted by Pankaj Arora <pa...@castiron.com>.
Hi Tushar,Oleg,
Can you please provide an OSGI bundle for httpcomponents-client-4.0-beta2-bin-with-dependencies.zip as you have for core and client separately?
Thanks,
Pankaj Arora
-----Original Message-----
From: Tushar Kapila [mailto:tushar.kapila.2@gmail.com]
Sent: Friday, January 16, 2009 9:18 AM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj
https://issues.apache.org/jira/browse/HTTPCORE-179
if you download the samples you can see a reference implementation and their
are 4 jars to be included in classpath from
http://www.apache.org/dist/httpcomponents/httpclient/binary/httpcomponents-client-4.0-beta2-bin-with-dependencies.zip
Oleg
I made a sample quick start guide - will need to edit it for reqiored jars
until the API, release file name patterns and locations stabalizes.
See it at http://wiki.apache.org/HttpComponents/QuickStart
Regards
Tushar Kapila
----- Original Message -----
From: "Pankaj Arora" <pa...@castiron.com>
To: "HttpComponents Project" <de...@hc.apache.org>
Sent: Friday, January 16, 2009 5:08 AM
Subject: RE: FW: HttpClient authentication problem.
Hi Oleg,
Thanks for your reply.
I have started porting the Api to 4.x and it looks like many of classes
namely org.apache.http.Header, org.apache.http.message.AbstractHttpMessage
etc are not part of the Http Components Client but are part of Http Core. So
to move to 4.x I need to have both Http Core libraries and Http Components
Client libraries?
Is that the case? Please verify.
Thanks,
Pankaj Arora
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Saturday, January 10, 2009 5:33 AM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj Arora wrote:
> Hi,
> I am using HttpClient 3.x till now. It looks like 4.x is completely
> overhauled and there are major API changes that happened. I thought
> solution to this problem lied in having authentication info available to
> connection managers so the stateful connection is not reused. I was
> looking at 4.x Api docs
> http://hc.apache.org/httpcomponents-client/httpclient/apidocs/index.html
> And I don't see any MultiThreaded Connection Manager.
http://hc.apache.org/httpcomponents-client/examples.html
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-client/src/examples/org/apache/http/examples/client/ClientMultiThreadedExecution.java
> In fact looks like everything has moved to org.apache.http.* packages from
> org.apache.commons.*.
> If that's the case,
Yes, this is the case, because 4.0 is a complete rewrite of the old code
line.
can you tell me if there is some guide that can tell me how I can make
my existing product compatible with 4.x release?
You need to port it to the new API.
> Second how the existing bug we are talking about can be resolved in new
> design.
>
HTTP connection managers in 4.0 are now aware that connections can be
stateful. They can take the connection state into consideration when
serving a request for a persistent connection. Standard connection
managers automatically take user identity into consideration when
managing NTLM authenticated connections.
Please make sure to read this, though
http://hc.apache.org/httpcomponents-client/ntlm.html
Oleg
> I am sorry as I am bit confused as I wasn't following 4.x development from
> scratch.
>
> Thanks,
> Pankaj Arora
>
> -----Original Message-----
> From: Pankaj Arora [mailto:parora@castiron.com]
> Sent: Tuesday, January 06, 2009 3:21 PM
> To: HttpComponents Project
> Subject: RE: FW: HttpClient authentication problem.
>
> Hi Odi and Roland,
> Was curious to know if this feature finally made to 4.0. Moreover when
> final 4.0 verison for commons is expected?
>
> Thanks,
> Pankaj Arora
>
>
> Hi Odi,
>
>> I would actually consider this a security issue in the connection
>> managers: It may hand out an already authenticated connection to an
>> unsuspecting client. We should add fields to HttpConnection that keep
>> track of the credentials for connection oriented AuthSchemes. So
>> connection managers can take this into account. Also the connection
>> managers lack a parameter in the getConnection methods that carries
>> authentication information for connection based auth schemes.
>
> It's on my list for 4.0, though it won't make it into client alpha1:
> http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign
> It's not urgent since we won't have NTLM support for a while.
>
> I don't think we can or should squeeze this into 3.x anymore.
>
> cheers,
> Roland
>
> -----Original Message-----
> From: Ortwin Glück [mailto:odi@odi.ch]
> Sent: Friday, May 18, 2007 5:41 AM
> To: HttpComponents Project
> Subject: Re: FW: HttpClient authentication problem.
>
> Pankaj,
>
> NTLM is designed to authenticate a connection. AFAIK it does not support
> a "logout" in the middle of a connection, nor does it support preemptive
> authentication. So the only way to force a new authentication is to
> close the connection. (e.g. try and clear the authentication to a mapped
> network drive in Windows. Probably the same issue there.)
>
> Thus it's not possible to share a connection between users when using
> NTLM auth. Yes, this may cause a performance hit if you were planning to
> share a connection between different users.
>
> You could tweak your connection manager to remember the authenticated
> user for each connection and try to find an already authenticated one or
> hand out a new one if you can't.
>
> I would actually consider this a security issue in the connection
> managers: It may hand out an already authenticated connection to an
> unsuspecting client. We should add fields to HttpConnection that keep
> track of the credentials for connection oriented AuthSchemes. So
> connection managers can take this into account. Also the connection
> managers lack a parameter in the getConnection methods that carries
> authentication information for connection based auth schemes.
>
> Ortwin
>
>
> Pankaj Arora wrote:
>> Thanks, That worked for me. Only thing that worries me is that
>> connections don't persist now. It might be a performance issue. Only
>> thing which I would like to know from you( as I am bit novice here)-
>> what is the right behavior, my client not authenticating second time
>> as connection is already authenticated or closing the connections to
>> force authentication repeatedly.
>>
>> Thanks, Pankaj Arora.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: FW: HttpClient authentication problem.
Posted by Tushar Kapila <tu...@gmail.com>.
Pankaj
https://issues.apache.org/jira/browse/HTTPCORE-179
if you download the samples you can see a reference implementation and their
are 4 jars to be included in classpath from
http://www.apache.org/dist/httpcomponents/httpclient/binary/httpcomponents-client-4.0-beta2-bin-with-dependencies.zip
Oleg
I made a sample quick start guide - will need to edit it for reqiored jars
until the API, release file name patterns and locations stabalizes.
See it at http://wiki.apache.org/HttpComponents/QuickStart
Regards
Tushar Kapila
----- Original Message -----
From: "Pankaj Arora" <pa...@castiron.com>
To: "HttpComponents Project" <de...@hc.apache.org>
Sent: Friday, January 16, 2009 5:08 AM
Subject: RE: FW: HttpClient authentication problem.
Hi Oleg,
Thanks for your reply.
I have started porting the Api to 4.x and it looks like many of classes
namely org.apache.http.Header, org.apache.http.message.AbstractHttpMessage
etc are not part of the Http Components Client but are part of Http Core. So
to move to 4.x I need to have both Http Core libraries and Http Components
Client libraries?
Is that the case? Please verify.
Thanks,
Pankaj Arora
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Saturday, January 10, 2009 5:33 AM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj Arora wrote:
> Hi,
> I am using HttpClient 3.x till now. It looks like 4.x is completely
> overhauled and there are major API changes that happened. I thought
> solution to this problem lied in having authentication info available to
> connection managers so the stateful connection is not reused. I was
> looking at 4.x Api docs
> http://hc.apache.org/httpcomponents-client/httpclient/apidocs/index.html
> And I don't see any MultiThreaded Connection Manager.
http://hc.apache.org/httpcomponents-client/examples.html
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-client/src/examples/org/apache/http/examples/client/ClientMultiThreadedExecution.java
> In fact looks like everything has moved to org.apache.http.* packages from
> org.apache.commons.*.
> If that's the case,
Yes, this is the case, because 4.0 is a complete rewrite of the old code
line.
can you tell me if there is some guide that can tell me how I can make
my existing product compatible with 4.x release?
You need to port it to the new API.
> Second how the existing bug we are talking about can be resolved in new
> design.
>
HTTP connection managers in 4.0 are now aware that connections can be
stateful. They can take the connection state into consideration when
serving a request for a persistent connection. Standard connection
managers automatically take user identity into consideration when
managing NTLM authenticated connections.
Please make sure to read this, though
http://hc.apache.org/httpcomponents-client/ntlm.html
Oleg
> I am sorry as I am bit confused as I wasn't following 4.x development from
> scratch.
>
> Thanks,
> Pankaj Arora
>
> -----Original Message-----
> From: Pankaj Arora [mailto:parora@castiron.com]
> Sent: Tuesday, January 06, 2009 3:21 PM
> To: HttpComponents Project
> Subject: RE: FW: HttpClient authentication problem.
>
> Hi Odi and Roland,
> Was curious to know if this feature finally made to 4.0. Moreover when
> final 4.0 verison for commons is expected?
>
> Thanks,
> Pankaj Arora
>
>
> Hi Odi,
>
>> I would actually consider this a security issue in the connection
>> managers: It may hand out an already authenticated connection to an
>> unsuspecting client. We should add fields to HttpConnection that keep
>> track of the credentials for connection oriented AuthSchemes. So
>> connection managers can take this into account. Also the connection
>> managers lack a parameter in the getConnection methods that carries
>> authentication information for connection based auth schemes.
>
> It's on my list for 4.0, though it won't make it into client alpha1:
> http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign
> It's not urgent since we won't have NTLM support for a while.
>
> I don't think we can or should squeeze this into 3.x anymore.
>
> cheers,
> Roland
>
> -----Original Message-----
> From: Ortwin Glück [mailto:odi@odi.ch]
> Sent: Friday, May 18, 2007 5:41 AM
> To: HttpComponents Project
> Subject: Re: FW: HttpClient authentication problem.
>
> Pankaj,
>
> NTLM is designed to authenticate a connection. AFAIK it does not support
> a "logout" in the middle of a connection, nor does it support preemptive
> authentication. So the only way to force a new authentication is to
> close the connection. (e.g. try and clear the authentication to a mapped
> network drive in Windows. Probably the same issue there.)
>
> Thus it's not possible to share a connection between users when using
> NTLM auth. Yes, this may cause a performance hit if you were planning to
> share a connection between different users.
>
> You could tweak your connection manager to remember the authenticated
> user for each connection and try to find an already authenticated one or
> hand out a new one if you can't.
>
> I would actually consider this a security issue in the connection
> managers: It may hand out an already authenticated connection to an
> unsuspecting client. We should add fields to HttpConnection that keep
> track of the credentials for connection oriented AuthSchemes. So
> connection managers can take this into account. Also the connection
> managers lack a parameter in the getConnection methods that carries
> authentication information for connection based auth schemes.
>
> Ortwin
>
>
> Pankaj Arora wrote:
>> Thanks, That worked for me. Only thing that worries me is that
>> connections don't persist now. It might be a performance issue. Only
>> thing which I would like to know from you( as I am bit novice here)-
>> what is the right behavior, my client not authenticating second time
>> as connection is already authenticated or closing the connections to
>> force authentication repeatedly.
>>
>> Thanks, Pankaj Arora.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
RE: FW: HttpClient authentication problem.
Posted by Pankaj Arora <pa...@castiron.com>.
Hi Oleg,
Thanks for your reply.
I have started porting the Api to 4.x and it looks like many of classes namely org.apache.http.Header, org.apache.http.message.AbstractHttpMessage etc are not part of the Http Components Client but are part of Http Core. So to move to 4.x I need to have both Http Core libraries and Http Components Client libraries?
Is that the case? Please verify.
Thanks,
Pankaj Arora
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Saturday, January 10, 2009 5:33 AM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj Arora wrote:
> Hi,
> I am using HttpClient 3.x till now. It looks like 4.x is completely overhauled and there are major API changes that happened. I thought solution to this problem lied in having authentication info available to connection managers so the stateful connection is not reused. I was looking at 4.x Api docs http://hc.apache.org/httpcomponents-client/httpclient/apidocs/index.html
> And I don't see any MultiThreaded Connection Manager.
http://hc.apache.org/httpcomponents-client/examples.html
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-client/src/examples/org/apache/http/examples/client/ClientMultiThreadedExecution.java
> In fact looks like everything has moved to org.apache.http.* packages from org.apache.commons.*.
> If that's the case,
Yes, this is the case, because 4.0 is a complete rewrite of the old code
line.
can you tell me if there is some guide that can tell me how I can make
my existing product compatible with 4.x release?
You need to port it to the new API.
> Second how the existing bug we are talking about can be resolved in new design.
>
HTTP connection managers in 4.0 are now aware that connections can be
stateful. They can take the connection state into consideration when
serving a request for a persistent connection. Standard connection
managers automatically take user identity into consideration when
managing NTLM authenticated connections.
Please make sure to read this, though
http://hc.apache.org/httpcomponents-client/ntlm.html
Oleg
> I am sorry as I am bit confused as I wasn't following 4.x development from scratch.
>
> Thanks,
> Pankaj Arora
>
> -----Original Message-----
> From: Pankaj Arora [mailto:parora@castiron.com]
> Sent: Tuesday, January 06, 2009 3:21 PM
> To: HttpComponents Project
> Subject: RE: FW: HttpClient authentication problem.
>
> Hi Odi and Roland,
> Was curious to know if this feature finally made to 4.0. Moreover when final 4.0 verison for commons is expected?
>
> Thanks,
> Pankaj Arora
>
>
> Hi Odi,
>
>> I would actually consider this a security issue in the connection
>> managers: It may hand out an already authenticated connection to an
>> unsuspecting client. We should add fields to HttpConnection that keep
>> track of the credentials for connection oriented AuthSchemes. So
>> connection managers can take this into account. Also the connection
>> managers lack a parameter in the getConnection methods that carries
>> authentication information for connection based auth schemes.
>
> It's on my list for 4.0, though it won't make it into client alpha1:
> http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign
> It's not urgent since we won't have NTLM support for a while.
>
> I don't think we can or should squeeze this into 3.x anymore.
>
> cheers,
> Roland
>
> -----Original Message-----
> From: Ortwin Glück [mailto:odi@odi.ch]
> Sent: Friday, May 18, 2007 5:41 AM
> To: HttpComponents Project
> Subject: Re: FW: HttpClient authentication problem.
>
> Pankaj,
>
> NTLM is designed to authenticate a connection. AFAIK it does not support
> a "logout" in the middle of a connection, nor does it support preemptive
> authentication. So the only way to force a new authentication is to
> close the connection. (e.g. try and clear the authentication to a mapped
> network drive in Windows. Probably the same issue there.)
>
> Thus it's not possible to share a connection between users when using
> NTLM auth. Yes, this may cause a performance hit if you were planning to
> share a connection between different users.
>
> You could tweak your connection manager to remember the authenticated
> user for each connection and try to find an already authenticated one or
> hand out a new one if you can't.
>
> I would actually consider this a security issue in the connection
> managers: It may hand out an already authenticated connection to an
> unsuspecting client. We should add fields to HttpConnection that keep
> track of the credentials for connection oriented AuthSchemes. So
> connection managers can take this into account. Also the connection
> managers lack a parameter in the getConnection methods that carries
> authentication information for connection based auth schemes.
>
> Ortwin
>
>
> Pankaj Arora wrote:
>> Thanks, That worked for me. Only thing that worries me is that
>> connections don't persist now. It might be a performance issue. Only
>> thing which I would like to know from you( as I am bit novice here)-
>> what is the right behavior, my client not authenticating second time
>> as connection is already authenticated or closing the connections to
>> force authentication repeatedly.
>>
>> Thanks, Pankaj Arora.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: FW: HttpClient authentication problem.
Posted by Oleg Kalnichevski <ol...@apache.org>.
Pankaj Arora wrote:
> Hi,
> I am using HttpClient 3.x till now. It looks like 4.x is completely overhauled and there are major API changes that happened. I thought solution to this problem lied in having authentication info available to connection managers so the stateful connection is not reused. I was looking at 4.x Api docs http://hc.apache.org/httpcomponents-client/httpclient/apidocs/index.html
> And I don't see any MultiThreaded Connection Manager.
http://hc.apache.org/httpcomponents-client/examples.html
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-client/src/examples/org/apache/http/examples/client/ClientMultiThreadedExecution.java
> In fact looks like everything has moved to org.apache.http.* packages from org.apache.commons.*.
> If that's the case,
Yes, this is the case, because 4.0 is a complete rewrite of the old code
line.
can you tell me if there is some guide that can tell me how I can make
my existing product compatible with 4.x release?
You need to port it to the new API.
> Second how the existing bug we are talking about can be resolved in new design.
>
HTTP connection managers in 4.0 are now aware that connections can be
stateful. They can take the connection state into consideration when
serving a request for a persistent connection. Standard connection
managers automatically take user identity into consideration when
managing NTLM authenticated connections.
Please make sure to read this, though
http://hc.apache.org/httpcomponents-client/ntlm.html
Oleg
> I am sorry as I am bit confused as I wasn't following 4.x development from scratch.
>
> Thanks,
> Pankaj Arora
>
> -----Original Message-----
> From: Pankaj Arora [mailto:parora@castiron.com]
> Sent: Tuesday, January 06, 2009 3:21 PM
> To: HttpComponents Project
> Subject: RE: FW: HttpClient authentication problem.
>
> Hi Odi and Roland,
> Was curious to know if this feature finally made to 4.0. Moreover when final 4.0 verison for commons is expected?
>
> Thanks,
> Pankaj Arora
>
>
> Hi Odi,
>
>> I would actually consider this a security issue in the connection
>> managers: It may hand out an already authenticated connection to an
>> unsuspecting client. We should add fields to HttpConnection that keep
>> track of the credentials for connection oriented AuthSchemes. So
>> connection managers can take this into account. Also the connection
>> managers lack a parameter in the getConnection methods that carries
>> authentication information for connection based auth schemes.
>
> It's on my list for 4.0, though it won't make it into client alpha1:
> http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign
> It's not urgent since we won't have NTLM support for a while.
>
> I don't think we can or should squeeze this into 3.x anymore.
>
> cheers,
> Roland
>
> -----Original Message-----
> From: Ortwin Glück [mailto:odi@odi.ch]
> Sent: Friday, May 18, 2007 5:41 AM
> To: HttpComponents Project
> Subject: Re: FW: HttpClient authentication problem.
>
> Pankaj,
>
> NTLM is designed to authenticate a connection. AFAIK it does not support
> a "logout" in the middle of a connection, nor does it support preemptive
> authentication. So the only way to force a new authentication is to
> close the connection. (e.g. try and clear the authentication to a mapped
> network drive in Windows. Probably the same issue there.)
>
> Thus it's not possible to share a connection between users when using
> NTLM auth. Yes, this may cause a performance hit if you were planning to
> share a connection between different users.
>
> You could tweak your connection manager to remember the authenticated
> user for each connection and try to find an already authenticated one or
> hand out a new one if you can't.
>
> I would actually consider this a security issue in the connection
> managers: It may hand out an already authenticated connection to an
> unsuspecting client. We should add fields to HttpConnection that keep
> track of the credentials for connection oriented AuthSchemes. So
> connection managers can take this into account. Also the connection
> managers lack a parameter in the getConnection methods that carries
> authentication information for connection based auth schemes.
>
> Ortwin
>
>
> Pankaj Arora wrote:
>> Thanks, That worked for me. Only thing that worries me is that
>> connections don't persist now. It might be a performance issue. Only
>> thing which I would like to know from you( as I am bit novice here)-
>> what is the right behavior, my client not authenticating second time
>> as connection is already authenticated or closing the connections to
>> force authentication repeatedly.
>>
>> Thanks, Pankaj Arora.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
RE: FW: HttpClient authentication problem.
Posted by Pankaj Arora <pa...@castiron.com>.
Hi,
I am using HttpClient 3.x till now. It looks like 4.x is completely overhauled and there are major API changes that happened. I thought solution to this problem lied in having authentication info available to connection managers so the stateful connection is not reused. I was looking at 4.x Api docs http://hc.apache.org/httpcomponents-client/httpclient/apidocs/index.html
And I don't see any MultiThreaded Connection Manager.
In fact looks like everything has moved to org.apache.http.* packages from org.apache.commons.*.
If that's the case, can you tell me if there is some guide that can tell me how I can make my existing product compatible with 4.x release?
Second how the existing bug we are talking about can be resolved in new design.
I am sorry as I am bit confused as I wasn't following 4.x development from scratch.
Thanks,
Pankaj Arora
-----Original Message-----
From: Pankaj Arora [mailto:parora@castiron.com]
Sent: Tuesday, January 06, 2009 3:21 PM
To: HttpComponents Project
Subject: RE: FW: HttpClient authentication problem.
Hi Odi and Roland,
Was curious to know if this feature finally made to 4.0. Moreover when final 4.0 verison for commons is expected?
Thanks,
Pankaj Arora
Hi Odi,
> I would actually consider this a security issue in the connection
> managers: It may hand out an already authenticated connection to an
> unsuspecting client. We should add fields to HttpConnection that keep
> track of the credentials for connection oriented AuthSchemes. So
> connection managers can take this into account. Also the connection
> managers lack a parameter in the getConnection methods that carries
> authentication information for connection based auth schemes.
It's on my list for 4.0, though it won't make it into client alpha1:
http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign
It's not urgent since we won't have NTLM support for a while.
I don't think we can or should squeeze this into 3.x anymore.
cheers,
Roland
-----Original Message-----
From: Ortwin Glück [mailto:odi@odi.ch]
Sent: Friday, May 18, 2007 5:41 AM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj,
NTLM is designed to authenticate a connection. AFAIK it does not support
a "logout" in the middle of a connection, nor does it support preemptive
authentication. So the only way to force a new authentication is to
close the connection. (e.g. try and clear the authentication to a mapped
network drive in Windows. Probably the same issue there.)
Thus it's not possible to share a connection between users when using
NTLM auth. Yes, this may cause a performance hit if you were planning to
share a connection between different users.
You could tweak your connection manager to remember the authenticated
user for each connection and try to find an already authenticated one or
hand out a new one if you can't.
I would actually consider this a security issue in the connection
managers: It may hand out an already authenticated connection to an
unsuspecting client. We should add fields to HttpConnection that keep
track of the credentials for connection oriented AuthSchemes. So
connection managers can take this into account. Also the connection
managers lack a parameter in the getConnection methods that carries
authentication information for connection based auth schemes.
Ortwin
Pankaj Arora wrote:
> Thanks, That worked for me. Only thing that worries me is that
> connections don't persist now. It might be a performance issue. Only
> thing which I would like to know from you( as I am bit novice here)-
> what is the right behavior, my client not authenticating second time
> as connection is already authenticated or closing the connections to
> force authentication repeatedly.
>
> Thanks, Pankaj Arora.
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
RE: FW: HttpClient authentication problem.
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2009-01-06 at 15:21 -0800, Pankaj Arora wrote:
> Hi Odi and Roland,
> Was curious to know if this feature finally made to 4.0.
Yes, it has
> Moreover when final 4.0 verison for commons is expected?
>
Q2 2009
Oleg
> Thanks,
> Pankaj Arora
>
>
> Hi Odi,
>
> > I would actually consider this a security issue in the connection
> > managers: It may hand out an already authenticated connection to an
> > unsuspecting client. We should add fields to HttpConnection that keep
> > track of the credentials for connection oriented AuthSchemes. So
> > connection managers can take this into account. Also the connection
> > managers lack a parameter in the getConnection methods that carries
> > authentication information for connection based auth schemes.
>
> It's on my list for 4.0, though it won't make it into client alpha1:
> http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign
> It's not urgent since we won't have NTLM support for a while.
>
> I don't think we can or should squeeze this into 3.x anymore.
>
> cheers,
> Roland
>
> -----Original Message-----
> From: Ortwin Glück [mailto:odi@odi.ch]
> Sent: Friday, May 18, 2007 5:41 AM
> To: HttpComponents Project
> Subject: Re: FW: HttpClient authentication problem.
>
> Pankaj,
>
> NTLM is designed to authenticate a connection. AFAIK it does not support
> a "logout" in the middle of a connection, nor does it support preemptive
> authentication. So the only way to force a new authentication is to
> close the connection. (e.g. try and clear the authentication to a mapped
> network drive in Windows. Probably the same issue there.)
>
> Thus it's not possible to share a connection between users when using
> NTLM auth. Yes, this may cause a performance hit if you were planning to
> share a connection between different users.
>
> You could tweak your connection manager to remember the authenticated
> user for each connection and try to find an already authenticated one or
> hand out a new one if you can't.
>
> I would actually consider this a security issue in the connection
> managers: It may hand out an already authenticated connection to an
> unsuspecting client. We should add fields to HttpConnection that keep
> track of the credentials for connection oriented AuthSchemes. So
> connection managers can take this into account. Also the connection
> managers lack a parameter in the getConnection methods that carries
> authentication information for connection based auth schemes.
>
> Ortwin
>
>
> Pankaj Arora wrote:
> > Thanks, That worked for me. Only thing that worries me is that
> > connections don't persist now. It might be a performance issue. Only
> > thing which I would like to know from you( as I am bit novice here)-
> > what is the right behavior, my client not authenticating second time
> > as connection is already authenticated or closing the connections to
> > force authentication repeatedly.
> >
> > Thanks, Pankaj Arora.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
RE: FW: HttpClient authentication problem.
Posted by Pankaj Arora <pa...@castiron.com>.
Hi Odi and Roland,
Was curious to know if this feature finally made to 4.0. Moreover when final 4.0 verison for commons is expected?
Thanks,
Pankaj Arora
Hi Odi,
> I would actually consider this a security issue in the connection
> managers: It may hand out an already authenticated connection to an
> unsuspecting client. We should add fields to HttpConnection that keep
> track of the credentials for connection oriented AuthSchemes. So
> connection managers can take this into account. Also the connection
> managers lack a parameter in the getConnection methods that carries
> authentication information for connection based auth schemes.
It's on my list for 4.0, though it won't make it into client alpha1:
http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign
It's not urgent since we won't have NTLM support for a while.
I don't think we can or should squeeze this into 3.x anymore.
cheers,
Roland
-----Original Message-----
From: Ortwin Glück [mailto:odi@odi.ch]
Sent: Friday, May 18, 2007 5:41 AM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj,
NTLM is designed to authenticate a connection. AFAIK it does not support
a "logout" in the middle of a connection, nor does it support preemptive
authentication. So the only way to force a new authentication is to
close the connection. (e.g. try and clear the authentication to a mapped
network drive in Windows. Probably the same issue there.)
Thus it's not possible to share a connection between users when using
NTLM auth. Yes, this may cause a performance hit if you were planning to
share a connection between different users.
You could tweak your connection manager to remember the authenticated
user for each connection and try to find an already authenticated one or
hand out a new one if you can't.
I would actually consider this a security issue in the connection
managers: It may hand out an already authenticated connection to an
unsuspecting client. We should add fields to HttpConnection that keep
track of the credentials for connection oriented AuthSchemes. So
connection managers can take this into account. Also the connection
managers lack a parameter in the getConnection methods that carries
authentication information for connection based auth schemes.
Ortwin
Pankaj Arora wrote:
> Thanks, That worked for me. Only thing that worries me is that
> connections don't persist now. It might be a performance issue. Only
> thing which I would like to know from you( as I am bit novice here)-
> what is the right behavior, my client not authenticating second time
> as connection is already authenticated or closing the connections to
> force authentication repeatedly.
>
> Thanks, Pankaj Arora.
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: FW: HttpClient authentication problem.
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2007-05-21 at 00:18 +0100, sebb wrote:
> On 20/05/07, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Sun, 2007-05-20 at 17:11 +0100, sebb wrote:
> > > On 20/05/07, Roland Weber <os...@dubioso.net> wrote:
> > > > Hi Oleg, Sebastian, all,
> > > >
> > > > > I _personally_ find the requirement of conditional compilation of LGPL
> > > > > dependent code too restrictive and complicating the release process,
> > > >
> > > > I agree, in particular if that should mean we can't release binaries
> > > > with NTLM support built in. But the conditional compilation is a
> > > > _Jakarta_ policy, not an Apache one. Let's see where we are a year
> > > > from now.
> > > >
> > > > sebb wrote:
> > > > > Quote:
> > > > >
> > > > > "Therefore, LGPL v2.1-licensed works must not be included in Apache
> > > > > products, although they may be listed as system requirements or
> > > > > distributed elsewhere as optional works."
> > > > >
> > > > > Seems to me that it should not be too difficult to make JCIFS an
> > > > > optional work.
> > > >
> > > > As I understand it, optional work would refer to hosting a separate
> > > > project elsewhere and using the LGPL for that. HttpAuth-NTLM or such.
> > >
> > > AIUI, it's not necessary to create an independent external project to
> > > merely to wrap libraries that cannot be included in distributions.
> > >
> > > For example, JMeter depends optionally on JavaMail - it will work
> > > without it, but some functions are disabled.
> > >
> >
> > Sebastian,
> >
> > The main sticking point is whether we are allowed to ship code that
> > imports LGPL licensed classes as a part of the main binary distribution
> > or the users will have to download the source distribution, rebuild the
> > whole damn thing with --allow-some-lgpl-stuff flag or some such in order
> > to enable an optional feature. If latter is the case I _personally_ see
> > the whole LGPL policy pointless and would rather favor hosting JCIFS
> > dependent code outside ASF.
>
> As far as I know, it's much the same for LGPL as for JavaMail.
> One cannot include the library, but can call it.
>
> See the link I quoted:
>
> "Scenarios Involving Prohibited Works
> ...
> YOU MAY include code within the Apache product necessary to achieve
> compatibility with a prohibited work through the use of API calls,
> "bridge code", or protocols ..."
>
> Is that not possible here?
>
I simply do not know. This does not help clarify ambiguity of the policy
stated here [1] with regards to binary distribution of optional LGPL
dependent functions
Oleg
[1] http://wiki.apache.org/jakarta/Using_LGPL'd_code
> S
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by sebb <se...@gmail.com>.
On 20/05/07, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sun, 2007-05-20 at 17:11 +0100, sebb wrote:
> > On 20/05/07, Roland Weber <os...@dubioso.net> wrote:
> > > Hi Oleg, Sebastian, all,
> > >
> > > > I _personally_ find the requirement of conditional compilation of LGPL
> > > > dependent code too restrictive and complicating the release process,
> > >
> > > I agree, in particular if that should mean we can't release binaries
> > > with NTLM support built in. But the conditional compilation is a
> > > _Jakarta_ policy, not an Apache one. Let's see where we are a year
> > > from now.
> > >
> > > sebb wrote:
> > > > Quote:
> > > >
> > > > "Therefore, LGPL v2.1-licensed works must not be included in Apache
> > > > products, although they may be listed as system requirements or
> > > > distributed elsewhere as optional works."
> > > >
> > > > Seems to me that it should not be too difficult to make JCIFS an
> > > > optional work.
> > >
> > > As I understand it, optional work would refer to hosting a separate
> > > project elsewhere and using the LGPL for that. HttpAuth-NTLM or such.
> >
> > AIUI, it's not necessary to create an independent external project to
> > merely to wrap libraries that cannot be included in distributions.
> >
> > For example, JMeter depends optionally on JavaMail - it will work
> > without it, but some functions are disabled.
> >
>
> Sebastian,
>
> The main sticking point is whether we are allowed to ship code that
> imports LGPL licensed classes as a part of the main binary distribution
> or the users will have to download the source distribution, rebuild the
> whole damn thing with --allow-some-lgpl-stuff flag or some such in order
> to enable an optional feature. If latter is the case I _personally_ see
> the whole LGPL policy pointless and would rather favor hosting JCIFS
> dependent code outside ASF.
As far as I know, it's much the same for LGPL as for JavaMail.
One cannot include the library, but can call it.
See the link I quoted:
"Scenarios Involving Prohibited Works
...
YOU MAY include code within the Apache product necessary to achieve
compatibility with a prohibited work through the use of API calls,
"bridge code", or protocols ..."
Is that not possible here?
S
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2007-05-20 at 17:11 +0100, sebb wrote:
> On 20/05/07, Roland Weber <os...@dubioso.net> wrote:
> > Hi Oleg, Sebastian, all,
> >
> > > I _personally_ find the requirement of conditional compilation of LGPL
> > > dependent code too restrictive and complicating the release process,
> >
> > I agree, in particular if that should mean we can't release binaries
> > with NTLM support built in. But the conditional compilation is a
> > _Jakarta_ policy, not an Apache one. Let's see where we are a year
> > from now.
> >
> > sebb wrote:
> > > Quote:
> > >
> > > "Therefore, LGPL v2.1-licensed works must not be included in Apache
> > > products, although they may be listed as system requirements or
> > > distributed elsewhere as optional works."
> > >
> > > Seems to me that it should not be too difficult to make JCIFS an
> > > optional work.
> >
> > As I understand it, optional work would refer to hosting a separate
> > project elsewhere and using the LGPL for that. HttpAuth-NTLM or such.
>
> AIUI, it's not necessary to create an independent external project to
> merely to wrap libraries that cannot be included in distributions.
>
> For example, JMeter depends optionally on JavaMail - it will work
> without it, but some functions are disabled.
>
Sebastian,
The main sticking point is whether we are allowed to ship code that
imports LGPL licensed classes as a part of the main binary distribution
or the users will have to download the source distribution, rebuild the
whole damn thing with --allow-some-lgpl-stuff flag or some such in order
to enable an optional feature. If latter is the case I _personally_ see
the whole LGPL policy pointless and would rather favor hosting JCIFS
dependent code outside ASF.
Oleg
> [See also https://issues.apache.org/jira/browse/HTTPCLIENT-293 which
> refers to HttpClient using JavaMail.]
>
> > But listing jCIFS as system requirement for using NTLM seems quite
> > reasonable to me. It wouldn't be included in our product.
>
> That would be an optional requirement.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by sebb <se...@gmail.com>.
On 20/05/07, Roland Weber <os...@dubioso.net> wrote:
> Hi Oleg, Sebastian, all,
>
> > I _personally_ find the requirement of conditional compilation of LGPL
> > dependent code too restrictive and complicating the release process,
>
> I agree, in particular if that should mean we can't release binaries
> with NTLM support built in. But the conditional compilation is a
> _Jakarta_ policy, not an Apache one. Let's see where we are a year
> from now.
>
> sebb wrote:
> > Quote:
> >
> > "Therefore, LGPL v2.1-licensed works must not be included in Apache
> > products, although they may be listed as system requirements or
> > distributed elsewhere as optional works."
> >
> > Seems to me that it should not be too difficult to make JCIFS an
> > optional work.
>
> As I understand it, optional work would refer to hosting a separate
> project elsewhere and using the LGPL for that. HttpAuth-NTLM or such.
AIUI, it's not necessary to create an independent external project to
merely to wrap libraries that cannot be included in distributions.
For example, JMeter depends optionally on JavaMail - it will work
without it, but some functions are disabled.
[See also https://issues.apache.org/jira/browse/HTTPCLIENT-293 which
refers to HttpClient using JavaMail.]
> But listing jCIFS as system requirement for using NTLM seems quite
> reasonable to me. It wouldn't be included in our product.
That would be an optional requirement.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: HttpClient logging
Posted by Roland Weber <os...@dubioso.net>.
Hello Pankaj,
Pankaj Arora wrote:
> Thanks. That worked. But I want more control at run time for logging on
> wire by httpclient.
> So what are advanced logging implementation, that can be used.
Please refer to the commons-logging documentation for available
implementations:
http://jakarta.apache.org/commons/logging/
You may also want to check out SLF4J, it is binary compatible
with Jakarta Commons Logging:
http://www.slf4j.org/
It's license is not Apache, but compatible.
Both frameworks will allow you to implement your own logging
backend if none of the defaults suit your needs.
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: Kerberos (SPNEGO support)
Posted by Pankaj Arora <pa...@castiron.com>.
That won't work for GSS-API. That's only for JAAS. I have written a
sample code, wich now works for me. I will contribute that soon.
-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com]
Sent: Saturday, August 18, 2007 4:58 PM
To: httpcomponents-dev@jakarta.apache.org
Subject: Fwd: Kerberos (SPNEGO support)
[Tried to send this earler, but DNS problems caused it to fail]
The Sun documentation:
http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/LoginS
ample.html
includes the words:
"the TextCallbackHandler class (from the
com.sun.security.auth.callback package) as the class to be used when
communicating with the user. This class can prompt the user for a user
name and password. "
HTH
On 14/08/07, Pankaj Arora <pa...@castiron.com> wrote:
> Thanks Roland.
> That code sample looks good.
> But I am facing a problem when I execute it. It prompts me for
username
> /password and provided correct credentials it does authenticate.
>
> Is it not possible programmatically to set username/password?
> Something similar to a callback Handler in LoginContext in the JAAS
> tutorial
> referred in the bug.
> https://issues.apache.org/jira/browse/HTTPCLIENT-523
>
> LoginContext con = null;
>
> try {
> // Create a LoginContext with a callback handler
> con = new LoginContext("com.sun.security.jgss.initiate",
> callbackHandler);
> }
>
>
> I don't see any API call in sun.security.jgss.GSSContextImpl to set
any
> callback function which may able me to set username/ password
> programmatically rather than from a prompt.
> My application can not take input from the user.
>
> Thanks,
> Pankaj Arora
>
>
> -----Original Message-----
> From: Roland Weber [mailto:ossfwot@dubioso.net]
> Sent: Friday, July 06, 2007 5:38 AM
> To: HttpComponents Project
> Subject: Re: Kerberos (SPNEGO support)
>
> Hello Pankaj,
>
> I believe it is possible:
> https://issues.apache.org/jira/browse/HTTPCLIENT-523
>
> The Subversion repository has recently moved, the code is now at:
>
http://svn.apache.org/repos/asf/jakarta/httpcomponents/oac.hc3x/trunk/sr
> c/contrib/org/apache/commons/httpclient/contrib/auth/
>
> hope that helps,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
httpcomponents-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Fwd: Kerberos (SPNEGO support)
Posted by sebb <se...@gmail.com>.
[Tried to send this earler, but DNS problems caused it to fail]
The Sun documentation:
http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/LoginSample.html
includes the words:
"the TextCallbackHandler class (from the
com.sun.security.auth.callback package) as the class to be used when
communicating with the user. This class can prompt the user for a user
name and password. "
HTH
On 14/08/07, Pankaj Arora <pa...@castiron.com> wrote:
> Thanks Roland.
> That code sample looks good.
> But I am facing a problem when I execute it. It prompts me for username
> /password and provided correct credentials it does authenticate.
>
> Is it not possible programmatically to set username/password?
> Something similar to a callback Handler in LoginContext in the JAAS
> tutorial
> referred in the bug.
> https://issues.apache.org/jira/browse/HTTPCLIENT-523
>
> LoginContext con = null;
>
> try {
> // Create a LoginContext with a callback handler
> con = new LoginContext("com.sun.security.jgss.initiate",
> callbackHandler);
> }
>
>
> I don't see any API call in sun.security.jgss.GSSContextImpl to set any
> callback function which may able me to set username/ password
> programmatically rather than from a prompt.
> My application can not take input from the user.
>
> Thanks,
> Pankaj Arora
>
>
> -----Original Message-----
> From: Roland Weber [mailto:ossfwot@dubioso.net]
> Sent: Friday, July 06, 2007 5:38 AM
> To: HttpComponents Project
> Subject: Re: Kerberos (SPNEGO support)
>
> Hello Pankaj,
>
> I believe it is possible:
> https://issues.apache.org/jira/browse/HTTPCLIENT-523
>
> The Subversion repository has recently moved, the code is now at:
> http://svn.apache.org/repos/asf/jakarta/httpcomponents/oac.hc3x/trunk/sr
> c/contrib/org/apache/commons/httpclient/contrib/auth/
>
> hope that helps,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: Kerberos (SPNEGO support)
Posted by Pankaj Arora <pa...@castiron.com>.
Thanks Roland.
That code sample looks good.
But I am facing a problem when I execute it. It prompts me for username
/password and provided correct credentials it does authenticate.
Is it not possible programmatically to set username/password?
Something similar to a callback Handler in LoginContext in the JAAS
tutorial
referred in the bug.
https://issues.apache.org/jira/browse/HTTPCLIENT-523
LoginContext con = null;
try {
// Create a LoginContext with a callback handler
con = new LoginContext("com.sun.security.jgss.initiate",
callbackHandler);
}
I don't see any API call in sun.security.jgss.GSSContextImpl to set any
callback function which may able me to set username/ password
programmatically rather than from a prompt.
My application can not take input from the user.
Thanks,
Pankaj Arora
-----Original Message-----
From: Roland Weber [mailto:ossfwot@dubioso.net]
Sent: Friday, July 06, 2007 5:38 AM
To: HttpComponents Project
Subject: Re: Kerberos (SPNEGO support)
Hello Pankaj,
I believe it is possible:
https://issues.apache.org/jira/browse/HTTPCLIENT-523
The Subversion repository has recently moved, the code is now at:
http://svn.apache.org/repos/asf/jakarta/httpcomponents/oac.hc3x/trunk/sr
c/contrib/org/apache/commons/httpclient/contrib/auth/
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail:
httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
httpcomponents-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Kerberos (SPNEGO support)
Posted by Roland Weber <os...@dubioso.net>.
Hello Pankaj,
I believe it is possible:
https://issues.apache.org/jira/browse/HTTPCLIENT-523
The Subversion repository has recently moved, the code is now at:
http://svn.apache.org/repos/asf/jakarta/httpcomponents/oac.hc3x/trunk/src/contrib/org/apache/commons/httpclient/contrib/auth/
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Kerberos (SPNEGO support)
Posted by Pankaj Arora <PA...@castiron.com>.
We need the ability to support Kerberos and NTLM Authentication in our
HTTP client so that we can post HTTP requests to Microsoft IIS based
applications.
For this purpose I need to add support for Simple and Protected GSSAPI
Negotiation Mechanism (SPNEGO) with support for Kerberos authentication
mechanisms.
Is it possible with Http Client? Please tell me if I can get some
examples on this.
Thanks,
Pankaj Arora
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Kerberos (SPNEGO support)
Posted by Pankaj Arora <PA...@castiron.com>.
We need the ability to support Kerberos and NTLM Authentication in our
HTTP client so that we can post HTTP requests to Microsoft IIS based
applications.
For this purpose I need to add support for Simple and Protected GSSAPI
Negotiation Mechanism (SPNEGO) with support for Kerberos authentication
mechanisms.
Is it possible with Http Client? Please tell me if I can get some
examples on this.
Thanks,
Pankaj Arora
-----Original Message-----
From: Pankaj Arora
Sent: Monday, May 28, 2007 3:07 AM
To: 'HttpComponents Project'
Subject: RE: HttpClient logging
Thanks. That worked. But I want more control at run time for logging on
wire by httpclient.
So what are advanced logging implementation, that can be used.
Thanks,
Pankaj Arora
-----Original Message-----
From: Roland Weber [mailto:ossfwot@dubioso.net]
Sent: Monday, May 28, 2007 2:02 PM
To: HttpComponents Project
Subject: Re: HttpClient logging
Hello Pankaj,
try setting the system properties _before_ you call into any HttpCLient
classes, that is before even creating the HttpClient object. Once a
logger is created, SimpleLog will not pick up changes to the system
properties. The settings are cached and will remain constant for the
lifetime of the JVM. If you need to adjust log levels at runtime, you'll
have to use a more advanced logging implementation.
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail:
httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
httpcomponents-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: HttpClient logging
Posted by Pankaj Arora <PA...@castiron.com>.
Thanks. That worked. But I want more control at run time for logging on
wire by httpclient.
So what are advanced logging implementation, that can be used.
Thanks,
Pankaj Arora
-----Original Message-----
From: Roland Weber [mailto:ossfwot@dubioso.net]
Sent: Monday, May 28, 2007 2:02 PM
To: HttpComponents Project
Subject: Re: HttpClient logging
Hello Pankaj,
try setting the system properties _before_ you call into any HttpCLient
classes, that is before even creating the HttpClient object. Once a
logger is created, SimpleLog will not pick up changes to the system
properties. The settings are cached and will remain constant for the
lifetime of the JVM. If you need to adjust log levels at runtime, you'll
have to use a more advanced logging implementation.
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail:
httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
httpcomponents-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: HttpClient logging
Posted by Roland Weber <os...@dubioso.net>.
Hello Pankaj,
try setting the system properties _before_ you call
into any HttpCLient classes, that is before even
creating the HttpClient object. Once a logger is
created, SimpleLog will not pick up changes to the
system properties. The settings are cached and will
remain constant for the lifetime of the JVM. If you
need to adjust log levels at runtime, you'll have
to use a more advanced logging implementation.
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
HttpClient logging
Posted by Pankaj Arora <PA...@castiron.com>.
Hi,
I am trying to programmatically tur on the log on wire for Http. I tried
using system properties as described in http logging guide.
http://jakarta.apache.org/commons/httpclient/logging.html.
But it seems as it doesn't take effect.
Below are 2 piece of code I wrote with/without logging on and both give
same output.
Code 1: Without logging:
________________________________________________________________________
________________________________________________
import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.*;
import org.apache.commons.httpclient.params.HttpMethodParams;
import org.apache.commons.httpclient.auth.*;
import org.apache.commons.httpclient.SimpleHttpConnectionManager;
//import org.apache.commons.*;
import java.io.*;
public class HttpClientNew_log {
private static String url = "http://tern:80/VAutomation/basic";
public static void main(String[] args) {
// Create an instance of HttpClient.
HttpClient client1 = new HttpClient();
HttpMethod _method1 = new GetMethod(url);
HttpState _httpState1 = new HttpState();
HostConfiguration hostConfig1 = new HostConfiguration();
hostConfig1.setHost("tern",80);
try {
// Execute the method.
int statusCode =
client1.executeMethod(hostConfig1,_method1,_httpState1);
System.out.println("Status code :" + statusCode);
if (statusCode != HttpStatus.SC_OK) {
System.err.println("Method failed: " + _method1.getStatusLine()
+ "StatusCode:" + statusCode);
}
// Read the response body.
byte[] responseBody = _method1.getResponseBody();
// Deal with the response.
// Use caution: ensure correct character encoding and is not
binary data
// System.out.println("Response Body is " + new
String(responseBody));
Header[] responseHeaders = _method1.getResponseHeaders();
// Header header;
System.out.println("----------------------------------------------------
-----------------------------------");
for( Header header : responseHeaders){
System.out.println("Headers is " + header.getName() + "and the
value is :" + header.getValue());
}
} catch (HttpException e) {
System.err.println("Fatal protocol violation: " + e.getMessage());
e.printStackTrace();
} catch (IOException e) {
System.err.println("Fatal transport error: " + e.getMessage());
e.printStackTrace();
} finally {
// Release the connection.
_method1.releaseConnection();
// _method2.releaseConnection();
}
}
}
________________________________________________________________________
__________________________________________________
Output:
Status code :200
May 27, 2007 9:11:48 PM org.apache.commons.httpclient.HttpMethodBase
getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using
getResponseBodyAsStream instead is recommended.
------------------------------------------------------------------------
---------------
Headers is Dateand the value is :Mon, 28 May 2007 04:38:32 GMT
Headers is Serverand the value is :Apache/2.0.40 (Red Hat Linux)
Headers is Connectionand the value is :close
Headers is Transfer-Encodingand the value is :chunked
Headers is Content-Typeand the value is :text/plain; charset=ISO-8859-1
Code 2 : Trying to switch logging programmatically:
________________________________________________________________________
_________________________________________
import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.*;
import org.apache.commons.httpclient.params.HttpMethodParams;
import org.apache.commons.httpclient.auth.*;
import org.apache.commons.httpclient.SimpleHttpConnectionManager;
//import org.apache.commons.*;
import java.io.*;
public class HttpClientNew_log {
private static String url = "http://tern:80/VAutomation/basic";
public static void main(String[] args) {
// Create an instance of HttpClient.
HttpClient client1 = new HttpClient();
HttpMethod _method1 = new GetMethod(url);
HttpState _httpState1 = new HttpState();
HostConfiguration hostConfig1 = new HostConfiguration();
hostConfig1.setHost("tern",80);
System.setProperty("org.apache.commons.logging.Log",
"org.apache.commons.logging.impl.SimpleLog");
System.setProperty("org.apache.commons.logging.simplelog.showdatetime",
"true");
System.setProperty("org.apache.commons.logging.simplelog.log.httpclient.
wire", "debug");
System.setProperty("org.apache.commons.logging.simplelog.log.org.apache.
commons.httpclient", "debug");
try {
// Execute the method.
int statusCode =
client1.executeMethod(hostConfig1,_method1,_httpState1);
System.out.println("Status code :" + statusCode);
if (statusCode != HttpStatus.SC_OK) {
System.err.println("Method failed: " + _method1.getStatusLine()
+ "StatusCode:" + statusCode);
}
// Read the response body.
byte[] responseBody = _method1.getResponseBody();
// Deal with the response.
// Use caution: ensure correct character encoding and is not
binary data
// System.out.println("Response Body is " + new
String(responseBody));
Header[] responseHeaders = _method1.getResponseHeaders();
// Header header;
System.out.println("----------------------------------------------------
-----------------------------------");
for( Header header : responseHeaders){
System.out.println("Headers is " + header.getName() + "and the
value is :" + header.getValue());
}
} catch (HttpException e) {
System.err.println("Fatal protocol violation: " + e.getMessage());
e.printStackTrace();
} catch (IOException e) {
System.err.println("Fatal transport error: " + e.getMessage());
e.printStackTrace();
} finally {
// Release the connection.
_method1.releaseConnection();
// _method2.releaseConnection();
}
}
}
________________________________________________________________________
______________________________________________
Output:
Status code :200
May 27, 2007 9:13:18 PM org.apache.commons.httpclient.HttpMethodBase
getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using
getResponseBodyAsStream instead is recommended.
------------------------------------------------------------------------
---------------
Headers is Dateand the value is :Mon, 28 May 2007 04:40:02 GMT
Headers is Serverand the value is :Apache/2.0.40 (Red Hat Linux)
Headers is Connectionand the value is :close
Headers is Transfer-Encodingand the value is :chunked
Headers is Content-Typeand the value is :text/plain; charset=ISO-8859-1
________________________________________________________________________
____________________________________________
I am expecting some more log on wire etc. for debugging purposes.
Please do tell me what I missed here. I have constraint that I need to
enable the log programmatically only.
Thanks,
Pankaj Arora
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Ortwin Glück <od...@odi.ch>.
sebb wrote:
> Quote:
>
> "Therefore, LGPL v2.1-licensed works must not be included in Apache
> products, although they may be listed as system requirements or
> distributed elsewhere as optional works."
>
> Seems to me that it should not be too difficult to make JCIFS an
> optional work.
Okay, in that sense.
Ortwin
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Roland Weber <os...@dubioso.net>.
Hi Oleg, Sebastian, all,
> I _personally_ find the requirement of conditional compilation of LGPL
> dependent code too restrictive and complicating the release process,
I agree, in particular if that should mean we can't release binaries
with NTLM support built in. But the conditional compilation is a
_Jakarta_ policy, not an Apache one. Let's see where we are a year
from now.
sebb wrote:
> Quote:
>
> "Therefore, LGPL v2.1-licensed works must not be included in Apache
> products, although they may be listed as system requirements or
> distributed elsewhere as optional works."
>
> Seems to me that it should not be too difficult to make JCIFS an
> optional work.
As I understand it, optional work would refer to hosting a separate
project elsewhere and using the LGPL for that. HttpAuth-NTLM or such.
But listing jCIFS as system requirement for using NTLM seems quite
reasonable to me. It wouldn't be included in our product.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2007-05-19 at 18:36 +0100, sebb wrote:
> On 19/05/07, Ortwin Glück <od...@odi.ch> wrote:
> >
> >
> > sebb wrote:
> > > http://www.apache.org/legal/3party.html
> > >
> > > shows the proposed rules, which don't seem to be particularly
> > > restrictive for LGPL.
> >
> > Excuse me, Sebastian, this page lists the LGPL under Category X. X for "must not
> > apply to any software within an Apache product". And you find that "not
> > particularly restrictive"? I'm a bit puzzled now, to say the least.
> >
> > Anyway, I didn't mean to kick off yet another discussion about including JCIFS
> > in Apache or not. I think all committers agree that we avoid the hell of
> > problems by doing such an integration outside of Apache.
> >
>
> Quote:
>
> "Therefore, LGPL v2.1-licensed works must not be included in Apache
> products, although they may be listed as system requirements or
> distributed elsewhere as optional works."
>
> Seems to me that it should not be too difficult to make JCIFS an optional work.
>
Folks
I _personally_ find the requirement of conditional compilation of LGPL
dependent code too restrictive and complicating the release process,
which is already complex enough. I _personally_ would very much rather
prefer simply to host those optional classes outside ASF.
Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by sebb <se...@gmail.com>.
On 19/05/07, Ortwin Glück <od...@odi.ch> wrote:
>
>
> sebb wrote:
> > http://www.apache.org/legal/3party.html
> >
> > shows the proposed rules, which don't seem to be particularly
> > restrictive for LGPL.
>
> Excuse me, Sebastian, this page lists the LGPL under Category X. X for "must not
> apply to any software within an Apache product". And you find that "not
> particularly restrictive"? I'm a bit puzzled now, to say the least.
>
> Anyway, I didn't mean to kick off yet another discussion about including JCIFS
> in Apache or not. I think all committers agree that we avoid the hell of
> problems by doing such an integration outside of Apache.
>
Quote:
"Therefore, LGPL v2.1-licensed works must not be included in Apache
products, although they may be listed as system requirements or
distributed elsewhere as optional works."
Seems to me that it should not be too difficult to make JCIFS an optional work.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Ortwin Glück <od...@odi.ch>.
sebb wrote:
> http://www.apache.org/legal/3party.html
>
> shows the proposed rules, which don't seem to be particularly
> restrictive for LGPL.
Excuse me, Sebastian, this page lists the LGPL under Category X. X for "must not
apply to any software within an Apache product". And you find that "not
particularly restrictive"? I'm a bit puzzled now, to say the least.
Anyway, I didn't mean to kick off yet another discussion about including JCIFS
in Apache or not. I think all committers agree that we avoid the hell of
problems by doing such an integration outside of Apache.
Ortwin
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by sebb <se...@gmail.com>.
On 19/05/07, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sat, 2007-05-19 at 15:45 +0200, Roland Weber wrote:
> > Ortwin Glück wrote:
> > >
> > > Roland Weber wrote:
> > >> The closest thing is jCIFS
> > >> which has support for LMv2, a subset of NTLMv2. But they are
> > >> GPL-licensed and not compatible with the Apache License.
> > >
> > > Just to be precise, JCIFS is LGLP, not GPL.
> >
> > Thanks, I don't know why I mixed that up. The FAQ is correct.
> >
> > > And LGPL is compatible under
> > > certain circumstances. We have had this dicussion many times before.
> >
> > Yes, and whenever Oleg mentioned it recently, he talked
> > about setting up a separate project outside of Apache.
> >
> > cheers,
> > Roland
> >
>
> Odi, Roland
>
> I am aware we no can make limited use of LGPL licensed cope provided
> several conditions are met [1]. I still find them too restrictive, so I
> tend to think we might be better off hosting JCIFS dependent code
> outside ASF altogether.
>
> Oleg
>
> [1] http://wiki.apache.org/jakarta/Using_LGPL'd_code
>
http://www.apache.org/legal/3party.html
shows the proposed rules, which don't seem to be particularly
restrictive for LGPL.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2007-05-19 at 15:45 +0200, Roland Weber wrote:
> Ortwin Glück wrote:
> >
> > Roland Weber wrote:
> >> The closest thing is jCIFS
> >> which has support for LMv2, a subset of NTLMv2. But they are
> >> GPL-licensed and not compatible with the Apache License.
> >
> > Just to be precise, JCIFS is LGLP, not GPL.
>
> Thanks, I don't know why I mixed that up. The FAQ is correct.
>
> > And LGPL is compatible under
> > certain circumstances. We have had this dicussion many times before.
>
> Yes, and whenever Oleg mentioned it recently, he talked
> about setting up a separate project outside of Apache.
>
> cheers,
> Roland
>
Odi, Roland
I am aware we no can make limited use of LGPL licensed cope provided
several conditions are met [1]. I still find them too restrictive, so I
tend to think we might be better off hosting JCIFS dependent code
outside ASF altogether.
Oleg
[1] http://wiki.apache.org/jakarta/Using_LGPL'd_code
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Roland Weber <os...@dubioso.net>.
Ortwin Glück wrote:
>
> Roland Weber wrote:
>> The closest thing is jCIFS
>> which has support for LMv2, a subset of NTLMv2. But they are
>> GPL-licensed and not compatible with the Apache License.
>
> Just to be precise, JCIFS is LGLP, not GPL.
Thanks, I don't know why I mixed that up. The FAQ is correct.
> And LGPL is compatible under
> certain circumstances. We have had this dicussion many times before.
Yes, and whenever Oleg mentioned it recently, he talked
about setting up a separate project outside of Apache.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Ortwin Glück <od...@odi.ch>.
Roland Weber wrote:
> The closest thing is jCIFS
> which has support for LMv2, a subset of NTLMv2. But they are
> GPL-licensed and not compatible with the Apache License.
Just to be precise, JCIFS is LGLP, not GPL. And LGPL is compatible under
certain circumstances. We have had this dicussion many times before.
Ortwin
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Roland Weber <os...@dubioso.net>.
Hello,
> So when is 4.0 expected
The first alpha in a few weeks, Oleg is working hard on it.
A reasonably stable alpha or the beta hardly before 2008.
> and is there a chance that NTLM v2 is also implemented.
No, there is no chance. As the authentication guide states:
> NT Lan Manager (NTLM) authentication is a proprietary, closed
> challenge/response authentication protocol for Microsoft Windows.
We're not in a position to sign IP licensing contracts with
Microsoft. There is no independent implementation of NTLMv2
available as Open Source Software. The closest thing is jCIFS
which has support for LMv2, a subset of NTLMv2. But they are
GPL-licensed and not compatible with the Apache License. We
can't link to their code without jumping through many loops.
There are thoughts about starting a non-Apache project that
would add LMv2 authentication via jCIFS. But there is no point
in such a project until HttpClient 3.0 has reached at least
a minor level of stability.
This question is also addressed in our NTLM FAQ:
http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedNTLMQuestions
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: FW: HttpClient authentication problem.
Posted by Pankaj Arora <PA...@castiron.com>.
Hi,
So when is 4.0 expected and is there a chance that NTLM v2 is also implemented. As the authentication guide states:
#
Cannot authenticate with Microsoft IIS using NTLM authentication scheme
NT Lan Manager (NTLM) authentication is a proprietary, closed challenge/response authentication protocol for Microsoft Windows. Only some details about NTLM protocol are available through reverse engineering. HttpClient provides limited support for what is known as NTLMv1, the early version of the NTLM protocol. HttpClient does not support NTLMv2 at all.
Workaround: Disable NTLMv2. For details refer to this Microsoft Support Article
I would like to use NTLM v 2.0 would be great if this can be added as well.
Thanks,
Pankaj Arora
-----Original Message-----
From: Roland Weber [mailto:ossfwot@dubioso.net]
Sent: Fri 5/18/2007 11:10 AM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Hi Odi,
> I would actually consider this a security issue in the connection
> managers: It may hand out an already authenticated connection to an
> unsuspecting client. We should add fields to HttpConnection that keep
> track of the credentials for connection oriented AuthSchemes. So
> connection managers can take this into account. Also the connection
> managers lack a parameter in the getConnection methods that carries
> authentication information for connection based auth schemes.
It's on my list for 4.0, though it won't make it into client alpha1:
http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign
It's not urgent since we won't have NTLM support for a while.
I don't think we can or should squeeze this into 3.x anymore.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Roland Weber <os...@dubioso.net>.
Hi Odi,
> I would actually consider this a security issue in the connection
> managers: It may hand out an already authenticated connection to an
> unsuspecting client. We should add fields to HttpConnection that keep
> track of the credentials for connection oriented AuthSchemes. So
> connection managers can take this into account. Also the connection
> managers lack a parameter in the getConnection methods that carries
> authentication information for connection based auth schemes.
It's on my list for 4.0, though it won't make it into client alpha1:
http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign
It's not urgent since we won't have NTLM support for a while.
I don't think we can or should squeeze this into 3.x anymore.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Ortwin Glück <od...@odi.ch>.
Pankaj,
NTLM is designed to authenticate a connection. AFAIK it does not support
a "logout" in the middle of a connection, nor does it support preemptive
authentication. So the only way to force a new authentication is to
close the connection. (e.g. try and clear the authentication to a mapped
network drive in Windows. Probably the same issue there.)
Thus it's not possible to share a connection between users when using
NTLM auth. Yes, this may cause a performance hit if you were planning to
share a connection between different users.
You could tweak your connection manager to remember the authenticated
user for each connection and try to find an already authenticated one or
hand out a new one if you can't.
I would actually consider this a security issue in the connection
managers: It may hand out an already authenticated connection to an
unsuspecting client. We should add fields to HttpConnection that keep
track of the credentials for connection oriented AuthSchemes. So
connection managers can take this into account. Also the connection
managers lack a parameter in the getConnection methods that carries
authentication information for connection based auth schemes.
Ortwin
Pankaj Arora wrote:
> Thanks, That worked for me. Only thing that worries me is that
> connections don't persist now. It might be a performance issue. Only
> thing which I would like to know from you( as I am bit novice here)-
> what is the right behavior, my client not authenticating second time
> as connection is already authenticated or closing the connections to
> force authentication repeatedly.
>
> Thanks, Pankaj Arora.
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: FW: HttpClient authentication problem.
Posted by Pankaj Arora <PA...@castiron.com>.
Thanks,
That worked for me. Only thing that worries me is that connections don't persist now. It might be a performance issue. Only thing which I would like to know from you( as I am bit novice here)- what is the right behavior, my client not authenticating second time as connection is already authenticated or closing the connections to force authentication repeatedly.
Thanks,
Pankaj Arora.
-----Original Message-----
From: Ortwin Glück [mailto:odi@odi.ch]
Sent: Friday, May 18, 2007 3:32 PM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj,
When always closing the connections it makes no sense to pool them. The MultithreadedConnectionManager is an overkill base class for this case, as it tries to do the exact oposite. Rather start a conn mgr from scratch. Look at the SimpleHttpConnectionManager for sample code.
getConnectionWithTimeout can just create a new connection every time.
public HttpConnection getConnectionWithTimeout(
HostConfiguration hostConfiguration, long timeout) {
HttpConnection httpConnection = new HttpConnection(hostConfiguration);
httpConnection.setHttpConnectionManager(this);
httpConnection.getParams().setDefaults(this.params);
return httpConnection;
}
and releaseConnection() can just close it:
public void releaseConnection(HttpConnection conn) {
if (conn != httpConnection) {
throw new IllegalStateException("Unexpected release of an unknown connection.");
}
httpConnection.close();
}
This connection manager can be completely stateless and thus unsynchronized.
Ortwin
Pankaj Arora wrote:
> But how to close connection while they are returned to pool.
> I completely missed this part. What to overload here?
>
> May be something like this ::
>
> Void releaseConnection(httpConnection connection){ connection.close();
> super.releaseConnection();
>
> }
> Right?
>
> Thanks,
> Pankaj Arora
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Ortwin Glück <od...@odi.ch>.
Pankaj,
When always closing the connections it makes no sense to pool them. The
MultithreadedConnectionManager is an overkill base class for this case,
as it tries to do the exact oposite. Rather start a conn mgr from
scratch. Look at the SimpleHttpConnectionManager for sample code.
getConnectionWithTimeout can just create a new connection every time.
public HttpConnection getConnectionWithTimeout(
HostConfiguration hostConfiguration, long timeout) {
HttpConnection httpConnection = new
HttpConnection(hostConfiguration);
httpConnection.setHttpConnectionManager(this);
httpConnection.getParams().setDefaults(this.params);
return httpConnection;
}
and releaseConnection() can just close it:
public void releaseConnection(HttpConnection conn) {
if (conn != httpConnection) {
throw new IllegalStateException("Unexpected release of an
unknown connection.");
}
httpConnection.close();
}
This connection manager can be completely stateless and thus unsynchronized.
Ortwin
Pankaj Arora wrote:
> But how to close connection while they are returned to pool.
> I completely missed this part. What to overload here?
>
> May be something like this ::
>
> Void releaseConnection(httpConnection connection){
> connection.close();
> super.releaseConnection();
>
> }
> Right?
>
> Thanks,
> Pankaj Arora
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: FW: HttpClient authentication problem.
Posted by Pankaj Arora <PA...@castiron.com>.
I do implemnet my own connection manager for some other reasons( Mainly cause I want to set the connection timeout as per host config).
So I do something like this :
HttpConnection getConnectionWithTimeout(HostConfiguration hostConfig,long timeout)
throws ConnectionPoolTimeoutException{
HttpConnection httpConnection = super.getConnectionWithTimeout(hostConfig,timeout);
//get the params from host params- if we didn't set it then set it to default value.
this.getParams().setConnectionTimeout(hostConfig.getParams().getIntParameter(HttpConstants.HTTP_CONNECTION_TIMEOUT,
HttpConstants.HTTP_DEFAULT_CONNECTION_TIMEOUT));
return httpConnection;
}
But how to close connection while they are returned to pool.
I completely missed this part. What to overload here?
May be something like this ::
Void releaseConnection(httpConnection connection){
connection.close();
super.releaseConnection();
}
Right?
Thanks,
Pankaj Arora
-----Original Message-----
From: Ortwin Glück [mailto:odi@odi.ch]
Sent: Friday, May 18, 2007 2:57 PM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj,
With the multithreaded conn manager you can try and set the
"Connection: close" header with each request. This should effectively disable keep-alive connections. If that doesn't work well with your server, it's probably best to implement your own connection manager that is thread-safe but still closes connections when they are returned to the "pool".
Oleg, Roland, do you see other possibilities?
Ortwin
Pankaj Arora wrote:
> Hi Ortwin,
> There is a problem:
>
> In real scenario- I am using a design which looks something like this
>
> Single instance of HttpClient->Single Instance of MultithreadedConnectionManger.
>
> Now these are used by multiple threads to acquire instance of
> client(which is created using a single instance of Multithreaded
> connection manager) and calls something like
>
> getSingletonInstance().executeMethod(hostconfig,method,state);
>
> Where
>
> HttpClient getSingletonInstance(){
> //This is implmented as singleton and returns new HttpClient(new
> MultithreadedConnectionManager());
> }
>
> Then each request is executed. Now until I undeploy(clean up) the whole application the second thread using the same instance of HttpClient do not authenticate for the second request.
>
> I understand that if I were using the SimpleHttpConnectionMAnger I could have used the new HttpClient(new SimpleHttpConnectionManager(true)); as suggested by you to close the connection and would have worked for me. I have tried and it do work for me.
>
>
> But in this case while using multithreaded connection manager I don't know what to do.
>
> Also please note that I am using the stable version 3.0.1 which doesn't have API call like you have just suggested.
> Though I have tried your suggestion on 3.1rc1 and it worked well.
>
> Will appreciate your thoughts on this.
>
> Thanks,
> Pankaj Arora
>
>
>
>
>
> -----Original Message-----
> From: Ortwin Glück [mailto:odi@odi.ch]
> Sent: Friday, May 18, 2007 1:44 PM
> To: HttpComponents Project
> Subject: Re: FW: HttpClient authentication problem.
>
> Pankaj,
>
> BASIC auth authenticates only a request.
> NTLM auth however authenticates a whole connection!
>
> So if the connection is reused no further authentication will be requested. That's what you are seeing. If you want to authenticate each request, you must make sure that the connection is closed after the request. You can achieve this by disabling connection pooling:
>
> new HttpClient(new SimpleHttpConnectionManager(true));
>
> Cheers
>
> Ortwin
>
> Pankaj Arora wrote:
>>
>>
>> ________________________________
>>
>> From: Pankaj Arora
>> Sent: Thursday, May 17, 2007 4:24 PM
>> To: 'httpcomponents-dev-info@jakarta.apache.org';
>> 'httpcomponents-dev-faq@jakarta.apache.org'
>> Subject: HttpClient authentication problem.
>>
>>
>> Hi,
>> I am using Http Client to authenticate to IIS web Server for doing
>> NTLM authentication. Here's the description of sample codes I am using:
>>
>>
>> Program1 :: This code create 2 state,method,host configuration and
>> use a single instance of httpClient to execute method. Please not
>> that in first go I give the correct credentials for NTLM
>> authentication and in the second go I give the wrong credentials. In
>> the response I observe that I get http code 200 and in second go I
>> don't even see authentication happening when data is captured over ethereal.
>>
>> Program2:: This code also create 2 state,method,host configuration
>> but use separate instance of httpClient to execute method. Please not
>> that in first go I give the correct credentials for NTLM
>> authentication and in the second go I give the wrong credentials. In
>> the response I observe that I get http code 200 and in second go I get response code as 401.
>>
>> The problem is I want to use single instance of HttpClient and also
>> want that session info is not maintained over the requests. Simply
>> speaking I want behavior 2 to happen when their is single instance of HttpClient.
>> Is there a way to do this?
>>
>>
>>
>> Code and response received from server for reference.
>>
>> Program1:
>> _____________________________________________________________________
>> _ __ ___________________________________________________________
>> // Create an instance of HttpClient.
>> HttpClient client1 = new HttpClient();
>> HttpMethod _method1 = new GetMethod(url);
>> HttpState _httpState1 = new HttpState();
>> HostConfiguration hostConfig1 = new HostConfiguration();
>> UsernamePasswordCredentials credentials1;
>> credentials1 = new
>> NTCredentials("administrator","password","host","domain");
>>
>> AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
>>
>> _httpState1.setCredentials(authScope1,credentials1);
>> hostConfig1.setHost("host"port);
>>
>> try {
>> // Execute the method.
>> int statusCode =
>> client1.executeMethod(hostConfig1,_method1,_httpState1);
>>
>> System.out.println("Status code :" + statusCode);
>> if (statusCode != HttpStatus.SC_OK) {
>> System.err.println("Method failed: " +
>> _method1.getStatusLine()
>> + "StatusCode:" + statusCode);
>> }
>>
>> // Read the response body.
>> byte[] responseBody = _method1.getResponseBody();
>>
>>
>> Header[] responseHeaders = _method1.getResponseHeaders();
>> // Header header;
>>
>> System.out.println("-------------------------------------------------
>> -
>> -- -----------------------------------");
>> for( Header header : responseHeaders){
>> System.out.println("Headers is " + header.getName() + "and the
>> value is :" + header.getValue());
>> }
>>
>>
>> HttpMethod _method2 = new GetMethod(url);
>> HttpState _httpState2 = new HttpState();
>> HostConfiguration hostConfig2 = new HostConfiguration();
>> UsernamePasswordCredentials credentials2;
>> credentials2 = new NTCredentials("administrator","wrong
>> password","host","domain");
>>
>> AuthScope authScope2 = new
>> AuthScope("host",port,"host","domain");
>>
>> _httpState2.setCredentials(authScope2,credentials2);
>> hostConfig2.setHost("host",port);
>> _httpState2.setCredentials(authScope2,credentials2);
>> statusCode =
>> client1.executeMethod(hostConfig2,_method2,_httpState2);
>>
>> System.out.println("Status code :" + statusCode);
>> if (statusCode != HttpStatus.SC_OK) {
>> System.err.println("Method failed: " +
>> _method2.getStatusLine()
>> + "StatusCode:" + statusCode);
>> }
>>
>> // Read the response body.
>> responseBody = _method2.getResponseBody();
>> responseHeaders = _method2.getResponseHeaders();
>> // Header header;
>>
>> System.out.println("-------------------------------------------------
>> -
>> -- -----------------------------------");
>> for( Header header : responseHeaders){
>> System.out.println("Headers is " + header.getName() + "and the
>> value is :" + header.getValue());
>> }
>> _____________________________________________________________________
>> _ __
>> __________________________________________________________________
>>
>> Response 1:
>> _____________________________________________________________________
>> _ __
>> ___________________________________________________________________
>> May 17, 2007 2:40:17 AM
>> org.apache.commons.httpclient.auth.AuthChallengeProcessor
>> selectAuthScheme
>> INFO: ntlm authentication scheme selected Status code :200
>> ---------------------------------------------------------------------
>> -
>> --
>> ---------------
>> Headers is Content-Lengthand the value is :51 Headers is
>> Content-Typeand the value is :text/html Headers is Last-Modifiedand
>> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
>> Accept-Rangesand the value is :bytes Headers is ETagand the value is
>> :"5cc42b1e717ec71:11d9"
>> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
>> Dateand the value is :Thu, 17 May 2007 09:30:53 GMT Status code :200
>> ---------------------------------------------------------------------
>> -
>> --
>> ---------------
>> Headers is Content-Lengthand the value is :51 Headers is
>> Content-Typeand the value is :text/html Headers is Last-Modifiedand
>> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
>> Accept-Rangesand the value is :bytes Headers is ETagand the value is
>> :"5cc42b1e717ec71:11d9"
>> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
>> Dateand the value is :Thu, 17 May 2007 09:30:53 GMT
>> _____________________________________________________________________
>> _ __ ____________________________________________________________
>>
>>
>> Program2:
>> _____________________________________________________________________
>> _ __ ______________________________________________________________
>>
>> // Create an instance of HttpClient.
>> HttpClient client1 = new HttpClient();
>> HttpMethod _method1 = new GetMethod(url);
>> HttpState _httpState1 = new HttpState();
>> HostConfiguration hostConfig1 = new HostConfiguration();
>> UsernamePasswordCredentials credentials1;
>> credentials1 = new
>> NTCredentials("administrator","password","host","domain");
>>
>> AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
>>
>> _httpState1.setCredentials(authScope1,credentials1);
>> hostConfig1.setHost("host"port);
>>
>> try {
>> // Execute the method.
>> int statusCode =
>> client1.executeMethod(hostConfig1,_method1,_httpState1);
>>
>> System.out.println("Status code :" + statusCode);
>> if (statusCode != HttpStatus.SC_OK) {
>> System.err.println("Method failed: " +
>> _method1.getStatusLine()
>> + "StatusCode:" + statusCode);
>> }
>>
>> // Read the response body.
>> byte[] responseBody = _method1.getResponseBody();
>>
>>
>> Header[] responseHeaders = _method1.getResponseHeaders();
>> // Header header;
>>
>> System.out.println("-------------------------------------------------
>> -
>> -- -----------------------------------");
>> for( Header header : responseHeaders){
>> System.out.println("Headers is " + header.getName() + "and the
>> value is :" + header.getValue());
>> }
>>
>> HttpClient client2 = new HttpClient();
>> HttpMethod _method2 = new GetMethod(url);
>> HttpState _httpState2 = new HttpState();
>> HostConfiguration hostConfig2 = new HostConfiguration();
>> UsernamePasswordCredentials credentials2;
>> credentials2 = new NTCredentials("administrator","wrong
>> password","host","domain");
>>
>> AuthScope authScope2 = new
>> AuthScope("host",port,"host","domain");
>>
>> _httpState2.setCredentials(authScope2,credentials2);
>> hostConfig2.setHost("host",port);
>> _httpState2.setCredentials(authScope2,credentials2);
>> statusCode =
>> client2.executeMethod(hostConfig2,_method2,_httpState2);
>>
>> System.out.println("Status code :" + statusCode);
>> if (statusCode != HttpStatus.SC_OK) {
>> System.err.println("Method failed: " +
>> _method2.getStatusLine()
>> + "StatusCode:" + statusCode);
>> }
>>
>> // Read the response body.
>> responseBody = _method2.getResponseBody();
>> responseHeaders = _method2.getResponseHeaders();
>> // Header header;
>>
>> System.out.println("-------------------------------------------------
>> -
>> -- -----------------------------------");
>> for( Header header : responseHeaders){
>> System.out.println("Headers is " + header.getName() + "and the
>> value is :" + header.getValue());
>> }
>> _____________________________________________________________________
>> _ __
>> __________________________________________________________________
>>
>> Response 2:
>> _____________________________________________________________________
>> _ __
>> ___________________________________________________________________
>> May 17, 2007 3:43:07 AM
>> org.apache.commons.httpclient.auth.AuthChallengeProcessor
>> selectAuthScheme
>> INFO: ntlm authentication scheme selected Status code :200
>> ---------------------------------------------------------------------
>> -
>> --
>> ---------------
>> Headers is Content-Lengthand the value is :51 Headers is
>> Content-Typeand the value is :text/html Headers is Last-Modifiedand
>> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
>> Accept-Rangesand the value is :bytes Headers is ETagand the value is
>> :"5cc42b1e717ec71:11e1"
>> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
>> Dateand the value is :Thu, 17 May 2007 10:33:42 GMT May 17, 2007
>> 3:43:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor
>> selectAuthScheme
>> INFO: ntlm authentication scheme selected May 17, 2007 3:43:08 AM
>> org.apache.commons.httpclient.HttpMethodDirector
>> processWWWAuthChallenge
>> INFO: Failure authenticating with NTLM <any realm>@vm3-ntlm-01:8589
>> Status code :401 Method failed: HTTP/1.1 401
>> UnauthorizedStatusCode:401
>> ---------------------------------------------------------------------
>> -
>> --
>> ---------------
>> Headers is Content-Lengthand the value is :1539 Headers is
>> Content-Typeand the value is :text/html Headers is Serverand the
>> value is :Microsoft-IIS/6.0 Headers is WWW-Authenticateand the value
>> is :Negotiate Headers is WWW-Authenticateand the value is :NTLM
>> Headers is Dateand the value is :Thu, 17 May 2007 10:33:42 GMT
>> _____________________________________________________________________
>> _ __ _______________________________________________________________
>>
>
> --
> [web] http://www.odi.ch/
> [blog] http://www.odi.ch/weblog/
> [pgp] key 0x81CF3416
> finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
>
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Ortwin Glück <od...@odi.ch>.
Pankaj,
With the multithreaded conn manager you can try and set the
"Connection: close" header with each request. This should effectively
disable keep-alive connections. If that doesn't work well with your
server, it's probably best to implement your own connection manager that
is thread-safe but still closes connections when they are returned to
the "pool".
Oleg, Roland, do you see other possibilities?
Ortwin
Pankaj Arora wrote:
> Hi Ortwin,
> There is a problem:
>
> In real scenario- I am using a design which looks something like this
>
> Single instance of HttpClient->Single Instance of MultithreadedConnectionManger.
>
> Now these are used by multiple threads to acquire instance of client(which is created using a single instance of Multithreaded connection manager) and calls something like
>
> getSingletonInstance().executeMethod(hostconfig,method,state);
>
> Where
>
> HttpClient getSingletonInstance(){
> //This is implmented as singleton and returns
> new HttpClient(new MultithreadedConnectionManager());
> }
>
> Then each request is executed. Now until I undeploy(clean up) the whole application the second thread using the same instance of HttpClient do not authenticate for the second request.
>
> I understand that if I were using the SimpleHttpConnectionMAnger I could have used the new HttpClient(new SimpleHttpConnectionManager(true)); as suggested by you to close the connection and would have worked for me. I have tried and it do work for me.
>
>
> But in this case while using multithreaded connection manager I don't know what to do.
>
> Also please note that I am using the stable version 3.0.1 which doesn't have API call like you have just suggested.
> Though I have tried your suggestion on 3.1rc1 and it worked well.
>
> Will appreciate your thoughts on this.
>
> Thanks,
> Pankaj Arora
>
>
>
>
>
> -----Original Message-----
> From: Ortwin Glück [mailto:odi@odi.ch]
> Sent: Friday, May 18, 2007 1:44 PM
> To: HttpComponents Project
> Subject: Re: FW: HttpClient authentication problem.
>
> Pankaj,
>
> BASIC auth authenticates only a request.
> NTLM auth however authenticates a whole connection!
>
> So if the connection is reused no further authentication will be requested. That's what you are seeing. If you want to authenticate each request, you must make sure that the connection is closed after the request. You can achieve this by disabling connection pooling:
>
> new HttpClient(new SimpleHttpConnectionManager(true));
>
> Cheers
>
> Ortwin
>
> Pankaj Arora wrote:
>>
>>
>> ________________________________
>>
>> From: Pankaj Arora
>> Sent: Thursday, May 17, 2007 4:24 PM
>> To: 'httpcomponents-dev-info@jakarta.apache.org';
>> 'httpcomponents-dev-faq@jakarta.apache.org'
>> Subject: HttpClient authentication problem.
>>
>>
>> Hi,
>> I am using Http Client to authenticate to IIS web Server for doing
>> NTLM authentication. Here's the description of sample codes I am using:
>>
>>
>> Program1 :: This code create 2 state,method,host configuration and use
>> a single instance of httpClient to execute method. Please not that in
>> first go I give the correct credentials for NTLM authentication and in
>> the second go I give the wrong credentials. In the response I observe
>> that I get http code 200 and in second go I don't even see
>> authentication happening when data is captured over ethereal.
>>
>> Program2:: This code also create 2 state,method,host configuration but
>> use separate instance of httpClient to execute method. Please not that
>> in first go I give the correct credentials for NTLM authentication and
>> in the second go I give the wrong credentials. In the response I
>> observe that I get http code 200 and in second go I get response code as 401.
>>
>> The problem is I want to use single instance of HttpClient and also
>> want that session info is not maintained over the requests. Simply
>> speaking I want behavior 2 to happen when their is single instance of HttpClient.
>> Is there a way to do this?
>>
>>
>>
>> Code and response received from server for reference.
>>
>> Program1:
>> ______________________________________________________________________
>> __ ___________________________________________________________
>> // Create an instance of HttpClient.
>> HttpClient client1 = new HttpClient();
>> HttpMethod _method1 = new GetMethod(url);
>> HttpState _httpState1 = new HttpState();
>> HostConfiguration hostConfig1 = new HostConfiguration();
>> UsernamePasswordCredentials credentials1;
>> credentials1 = new
>> NTCredentials("administrator","password","host","domain");
>>
>> AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
>>
>> _httpState1.setCredentials(authScope1,credentials1);
>> hostConfig1.setHost("host"port);
>>
>> try {
>> // Execute the method.
>> int statusCode =
>> client1.executeMethod(hostConfig1,_method1,_httpState1);
>>
>> System.out.println("Status code :" + statusCode);
>> if (statusCode != HttpStatus.SC_OK) {
>> System.err.println("Method failed: " +
>> _method1.getStatusLine()
>> + "StatusCode:" + statusCode);
>> }
>>
>> // Read the response body.
>> byte[] responseBody = _method1.getResponseBody();
>>
>>
>> Header[] responseHeaders = _method1.getResponseHeaders();
>> // Header header;
>>
>> System.out.println("--------------------------------------------------
>> -- -----------------------------------");
>> for( Header header : responseHeaders){
>> System.out.println("Headers is " + header.getName() + "and the
>> value is :" + header.getValue());
>> }
>>
>>
>> HttpMethod _method2 = new GetMethod(url);
>> HttpState _httpState2 = new HttpState();
>> HostConfiguration hostConfig2 = new HostConfiguration();
>> UsernamePasswordCredentials credentials2;
>> credentials2 = new NTCredentials("administrator","wrong
>> password","host","domain");
>>
>> AuthScope authScope2 = new AuthScope("host",port,"host","domain");
>>
>> _httpState2.setCredentials(authScope2,credentials2);
>> hostConfig2.setHost("host",port);
>> _httpState2.setCredentials(authScope2,credentials2);
>> statusCode =
>> client1.executeMethod(hostConfig2,_method2,_httpState2);
>>
>> System.out.println("Status code :" + statusCode);
>> if (statusCode != HttpStatus.SC_OK) {
>> System.err.println("Method failed: " +
>> _method2.getStatusLine()
>> + "StatusCode:" + statusCode);
>> }
>>
>> // Read the response body.
>> responseBody = _method2.getResponseBody();
>> responseHeaders = _method2.getResponseHeaders();
>> // Header header;
>>
>> System.out.println("--------------------------------------------------
>> -- -----------------------------------");
>> for( Header header : responseHeaders){
>> System.out.println("Headers is " + header.getName() + "and the
>> value is :" + header.getValue());
>> }
>> ______________________________________________________________________
>> __ __________________________________________________________________
>>
>> Response 1:
>> ______________________________________________________________________
>> __ ___________________________________________________________________
>> May 17, 2007 2:40:17 AM
>> org.apache.commons.httpclient.auth.AuthChallengeProcessor
>> selectAuthScheme
>> INFO: ntlm authentication scheme selected Status code :200
>> ----------------------------------------------------------------------
>> --
>> ---------------
>> Headers is Content-Lengthand the value is :51 Headers is
>> Content-Typeand the value is :text/html Headers is Last-Modifiedand
>> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
>> Accept-Rangesand the value is :bytes Headers is ETagand the value is
>> :"5cc42b1e717ec71:11d9"
>> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
>> Dateand the value is :Thu, 17 May 2007 09:30:53 GMT Status code :200
>> ----------------------------------------------------------------------
>> --
>> ---------------
>> Headers is Content-Lengthand the value is :51 Headers is
>> Content-Typeand the value is :text/html Headers is Last-Modifiedand
>> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
>> Accept-Rangesand the value is :bytes Headers is ETagand the value is
>> :"5cc42b1e717ec71:11d9"
>> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
>> Dateand the value is :Thu, 17 May 2007 09:30:53 GMT
>> ______________________________________________________________________
>> __ ____________________________________________________________
>>
>>
>> Program2:
>> ______________________________________________________________________
>> __ ______________________________________________________________
>>
>> // Create an instance of HttpClient.
>> HttpClient client1 = new HttpClient();
>> HttpMethod _method1 = new GetMethod(url);
>> HttpState _httpState1 = new HttpState();
>> HostConfiguration hostConfig1 = new HostConfiguration();
>> UsernamePasswordCredentials credentials1;
>> credentials1 = new
>> NTCredentials("administrator","password","host","domain");
>>
>> AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
>>
>> _httpState1.setCredentials(authScope1,credentials1);
>> hostConfig1.setHost("host"port);
>>
>> try {
>> // Execute the method.
>> int statusCode =
>> client1.executeMethod(hostConfig1,_method1,_httpState1);
>>
>> System.out.println("Status code :" + statusCode);
>> if (statusCode != HttpStatus.SC_OK) {
>> System.err.println("Method failed: " +
>> _method1.getStatusLine()
>> + "StatusCode:" + statusCode);
>> }
>>
>> // Read the response body.
>> byte[] responseBody = _method1.getResponseBody();
>>
>>
>> Header[] responseHeaders = _method1.getResponseHeaders();
>> // Header header;
>>
>> System.out.println("--------------------------------------------------
>> -- -----------------------------------");
>> for( Header header : responseHeaders){
>> System.out.println("Headers is " + header.getName() + "and the
>> value is :" + header.getValue());
>> }
>>
>> HttpClient client2 = new HttpClient();
>> HttpMethod _method2 = new GetMethod(url);
>> HttpState _httpState2 = new HttpState();
>> HostConfiguration hostConfig2 = new HostConfiguration();
>> UsernamePasswordCredentials credentials2;
>> credentials2 = new NTCredentials("administrator","wrong
>> password","host","domain");
>>
>> AuthScope authScope2 = new AuthScope("host",port,"host","domain");
>>
>> _httpState2.setCredentials(authScope2,credentials2);
>> hostConfig2.setHost("host",port);
>> _httpState2.setCredentials(authScope2,credentials2);
>> statusCode =
>> client2.executeMethod(hostConfig2,_method2,_httpState2);
>>
>> System.out.println("Status code :" + statusCode);
>> if (statusCode != HttpStatus.SC_OK) {
>> System.err.println("Method failed: " +
>> _method2.getStatusLine()
>> + "StatusCode:" + statusCode);
>> }
>>
>> // Read the response body.
>> responseBody = _method2.getResponseBody();
>> responseHeaders = _method2.getResponseHeaders();
>> // Header header;
>>
>> System.out.println("--------------------------------------------------
>> -- -----------------------------------");
>> for( Header header : responseHeaders){
>> System.out.println("Headers is " + header.getName() + "and the
>> value is :" + header.getValue());
>> }
>> ______________________________________________________________________
>> __ __________________________________________________________________
>>
>> Response 2:
>> ______________________________________________________________________
>> __ ___________________________________________________________________
>> May 17, 2007 3:43:07 AM
>> org.apache.commons.httpclient.auth.AuthChallengeProcessor
>> selectAuthScheme
>> INFO: ntlm authentication scheme selected Status code :200
>> ----------------------------------------------------------------------
>> --
>> ---------------
>> Headers is Content-Lengthand the value is :51 Headers is
>> Content-Typeand the value is :text/html Headers is Last-Modifiedand
>> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
>> Accept-Rangesand the value is :bytes Headers is ETagand the value is
>> :"5cc42b1e717ec71:11e1"
>> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
>> Dateand the value is :Thu, 17 May 2007 10:33:42 GMT May 17, 2007
>> 3:43:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor
>> selectAuthScheme
>> INFO: ntlm authentication scheme selected May 17, 2007 3:43:08 AM
>> org.apache.commons.httpclient.HttpMethodDirector
>> processWWWAuthChallenge
>> INFO: Failure authenticating with NTLM <any realm>@vm3-ntlm-01:8589
>> Status code :401 Method failed: HTTP/1.1 401
>> UnauthorizedStatusCode:401
>> ----------------------------------------------------------------------
>> --
>> ---------------
>> Headers is Content-Lengthand the value is :1539 Headers is
>> Content-Typeand the value is :text/html Headers is Serverand the value
>> is :Microsoft-IIS/6.0 Headers is WWW-Authenticateand the value is
>> :Negotiate Headers is WWW-Authenticateand the value is :NTLM Headers
>> is Dateand the value is :Thu, 17 May 2007 10:33:42 GMT
>> ______________________________________________________________________
>> __ _______________________________________________________________
>>
>
> --
> [web] http://www.odi.ch/
> [blog] http://www.odi.ch/weblog/
> [pgp] key 0x81CF3416
> finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: FW: HttpClient authentication problem.
Posted by Pankaj Arora <PA...@castiron.com>.
Hi Ortwin,
There is a problem:
In real scenario- I am using a design which looks something like this
Single instance of HttpClient->Single Instance of MultithreadedConnectionManger.
Now these are used by multiple threads to acquire instance of client(which is created using a single instance of Multithreaded connection manager) and calls something like
getSingletonInstance().executeMethod(hostconfig,method,state);
Where
HttpClient getSingletonInstance(){
//This is implmented as singleton and returns
new HttpClient(new MultithreadedConnectionManager());
}
Then each request is executed. Now until I undeploy(clean up) the whole application the second thread using the same instance of HttpClient do not authenticate for the second request.
I understand that if I were using the SimpleHttpConnectionMAnger I could have used the new HttpClient(new SimpleHttpConnectionManager(true)); as suggested by you to close the connection and would have worked for me. I have tried and it do work for me.
But in this case while using multithreaded connection manager I don't know what to do.
Also please note that I am using the stable version 3.0.1 which doesn't have API call like you have just suggested.
Though I have tried your suggestion on 3.1rc1 and it worked well.
Will appreciate your thoughts on this.
Thanks,
Pankaj Arora
-----Original Message-----
From: Ortwin Glück [mailto:odi@odi.ch]
Sent: Friday, May 18, 2007 1:44 PM
To: HttpComponents Project
Subject: Re: FW: HttpClient authentication problem.
Pankaj,
BASIC auth authenticates only a request.
NTLM auth however authenticates a whole connection!
So if the connection is reused no further authentication will be requested. That's what you are seeing. If you want to authenticate each request, you must make sure that the connection is closed after the request. You can achieve this by disabling connection pooling:
new HttpClient(new SimpleHttpConnectionManager(true));
Cheers
Ortwin
Pankaj Arora wrote:
>
>
> ________________________________
>
> From: Pankaj Arora
> Sent: Thursday, May 17, 2007 4:24 PM
> To: 'httpcomponents-dev-info@jakarta.apache.org';
> 'httpcomponents-dev-faq@jakarta.apache.org'
> Subject: HttpClient authentication problem.
>
>
> Hi,
> I am using Http Client to authenticate to IIS web Server for doing
> NTLM authentication. Here's the description of sample codes I am using:
>
>
> Program1 :: This code create 2 state,method,host configuration and use
> a single instance of httpClient to execute method. Please not that in
> first go I give the correct credentials for NTLM authentication and in
> the second go I give the wrong credentials. In the response I observe
> that I get http code 200 and in second go I don't even see
> authentication happening when data is captured over ethereal.
>
> Program2:: This code also create 2 state,method,host configuration but
> use separate instance of httpClient to execute method. Please not that
> in first go I give the correct credentials for NTLM authentication and
> in the second go I give the wrong credentials. In the response I
> observe that I get http code 200 and in second go I get response code as 401.
>
> The problem is I want to use single instance of HttpClient and also
> want that session info is not maintained over the requests. Simply
> speaking I want behavior 2 to happen when their is single instance of HttpClient.
> Is there a way to do this?
>
>
>
> Code and response received from server for reference.
>
> Program1:
> ______________________________________________________________________
> __ ___________________________________________________________
> // Create an instance of HttpClient.
> HttpClient client1 = new HttpClient();
> HttpMethod _method1 = new GetMethod(url);
> HttpState _httpState1 = new HttpState();
> HostConfiguration hostConfig1 = new HostConfiguration();
> UsernamePasswordCredentials credentials1;
> credentials1 = new
> NTCredentials("administrator","password","host","domain");
>
> AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
>
> _httpState1.setCredentials(authScope1,credentials1);
> hostConfig1.setHost("host"port);
>
> try {
> // Execute the method.
> int statusCode =
> client1.executeMethod(hostConfig1,_method1,_httpState1);
>
> System.out.println("Status code :" + statusCode);
> if (statusCode != HttpStatus.SC_OK) {
> System.err.println("Method failed: " +
> _method1.getStatusLine()
> + "StatusCode:" + statusCode);
> }
>
> // Read the response body.
> byte[] responseBody = _method1.getResponseBody();
>
>
> Header[] responseHeaders = _method1.getResponseHeaders();
> // Header header;
>
> System.out.println("--------------------------------------------------
> -- -----------------------------------");
> for( Header header : responseHeaders){
> System.out.println("Headers is " + header.getName() + "and the
> value is :" + header.getValue());
> }
>
>
> HttpMethod _method2 = new GetMethod(url);
> HttpState _httpState2 = new HttpState();
> HostConfiguration hostConfig2 = new HostConfiguration();
> UsernamePasswordCredentials credentials2;
> credentials2 = new NTCredentials("administrator","wrong
> password","host","domain");
>
> AuthScope authScope2 = new AuthScope("host",port,"host","domain");
>
> _httpState2.setCredentials(authScope2,credentials2);
> hostConfig2.setHost("host",port);
> _httpState2.setCredentials(authScope2,credentials2);
> statusCode =
> client1.executeMethod(hostConfig2,_method2,_httpState2);
>
> System.out.println("Status code :" + statusCode);
> if (statusCode != HttpStatus.SC_OK) {
> System.err.println("Method failed: " +
> _method2.getStatusLine()
> + "StatusCode:" + statusCode);
> }
>
> // Read the response body.
> responseBody = _method2.getResponseBody();
> responseHeaders = _method2.getResponseHeaders();
> // Header header;
>
> System.out.println("--------------------------------------------------
> -- -----------------------------------");
> for( Header header : responseHeaders){
> System.out.println("Headers is " + header.getName() + "and the
> value is :" + header.getValue());
> }
> ______________________________________________________________________
> __ __________________________________________________________________
>
> Response 1:
> ______________________________________________________________________
> __ ___________________________________________________________________
> May 17, 2007 2:40:17 AM
> org.apache.commons.httpclient.auth.AuthChallengeProcessor
> selectAuthScheme
> INFO: ntlm authentication scheme selected Status code :200
> ----------------------------------------------------------------------
> --
> ---------------
> Headers is Content-Lengthand the value is :51 Headers is
> Content-Typeand the value is :text/html Headers is Last-Modifiedand
> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
> Accept-Rangesand the value is :bytes Headers is ETagand the value is
> :"5cc42b1e717ec71:11d9"
> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
> Dateand the value is :Thu, 17 May 2007 09:30:53 GMT Status code :200
> ----------------------------------------------------------------------
> --
> ---------------
> Headers is Content-Lengthand the value is :51 Headers is
> Content-Typeand the value is :text/html Headers is Last-Modifiedand
> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
> Accept-Rangesand the value is :bytes Headers is ETagand the value is
> :"5cc42b1e717ec71:11d9"
> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
> Dateand the value is :Thu, 17 May 2007 09:30:53 GMT
> ______________________________________________________________________
> __ ____________________________________________________________
>
>
> Program2:
> ______________________________________________________________________
> __ ______________________________________________________________
>
> // Create an instance of HttpClient.
> HttpClient client1 = new HttpClient();
> HttpMethod _method1 = new GetMethod(url);
> HttpState _httpState1 = new HttpState();
> HostConfiguration hostConfig1 = new HostConfiguration();
> UsernamePasswordCredentials credentials1;
> credentials1 = new
> NTCredentials("administrator","password","host","domain");
>
> AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
>
> _httpState1.setCredentials(authScope1,credentials1);
> hostConfig1.setHost("host"port);
>
> try {
> // Execute the method.
> int statusCode =
> client1.executeMethod(hostConfig1,_method1,_httpState1);
>
> System.out.println("Status code :" + statusCode);
> if (statusCode != HttpStatus.SC_OK) {
> System.err.println("Method failed: " +
> _method1.getStatusLine()
> + "StatusCode:" + statusCode);
> }
>
> // Read the response body.
> byte[] responseBody = _method1.getResponseBody();
>
>
> Header[] responseHeaders = _method1.getResponseHeaders();
> // Header header;
>
> System.out.println("--------------------------------------------------
> -- -----------------------------------");
> for( Header header : responseHeaders){
> System.out.println("Headers is " + header.getName() + "and the
> value is :" + header.getValue());
> }
>
> HttpClient client2 = new HttpClient();
> HttpMethod _method2 = new GetMethod(url);
> HttpState _httpState2 = new HttpState();
> HostConfiguration hostConfig2 = new HostConfiguration();
> UsernamePasswordCredentials credentials2;
> credentials2 = new NTCredentials("administrator","wrong
> password","host","domain");
>
> AuthScope authScope2 = new AuthScope("host",port,"host","domain");
>
> _httpState2.setCredentials(authScope2,credentials2);
> hostConfig2.setHost("host",port);
> _httpState2.setCredentials(authScope2,credentials2);
> statusCode =
> client2.executeMethod(hostConfig2,_method2,_httpState2);
>
> System.out.println("Status code :" + statusCode);
> if (statusCode != HttpStatus.SC_OK) {
> System.err.println("Method failed: " +
> _method2.getStatusLine()
> + "StatusCode:" + statusCode);
> }
>
> // Read the response body.
> responseBody = _method2.getResponseBody();
> responseHeaders = _method2.getResponseHeaders();
> // Header header;
>
> System.out.println("--------------------------------------------------
> -- -----------------------------------");
> for( Header header : responseHeaders){
> System.out.println("Headers is " + header.getName() + "and the
> value is :" + header.getValue());
> }
> ______________________________________________________________________
> __ __________________________________________________________________
>
> Response 2:
> ______________________________________________________________________
> __ ___________________________________________________________________
> May 17, 2007 3:43:07 AM
> org.apache.commons.httpclient.auth.AuthChallengeProcessor
> selectAuthScheme
> INFO: ntlm authentication scheme selected Status code :200
> ----------------------------------------------------------------------
> --
> ---------------
> Headers is Content-Lengthand the value is :51 Headers is
> Content-Typeand the value is :text/html Headers is Last-Modifiedand
> the value is :Sat, 14 Apr 2007 08:44:30 GMT Headers is
> Accept-Rangesand the value is :bytes Headers is ETagand the value is
> :"5cc42b1e717ec71:11e1"
> Headers is Serverand the value is :Microsoft-IIS/6.0 Headers is
> Dateand the value is :Thu, 17 May 2007 10:33:42 GMT May 17, 2007
> 3:43:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor
> selectAuthScheme
> INFO: ntlm authentication scheme selected May 17, 2007 3:43:08 AM
> org.apache.commons.httpclient.HttpMethodDirector
> processWWWAuthChallenge
> INFO: Failure authenticating with NTLM <any realm>@vm3-ntlm-01:8589
> Status code :401 Method failed: HTTP/1.1 401
> UnauthorizedStatusCode:401
> ----------------------------------------------------------------------
> --
> ---------------
> Headers is Content-Lengthand the value is :1539 Headers is
> Content-Typeand the value is :text/html Headers is Serverand the value
> is :Microsoft-IIS/6.0 Headers is WWW-Authenticateand the value is
> :Negotiate Headers is WWW-Authenticateand the value is :NTLM Headers
> is Dateand the value is :Thu, 17 May 2007 10:33:42 GMT
> ______________________________________________________________________
> __ _______________________________________________________________
>
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: FW: HttpClient authentication problem.
Posted by Ortwin Glück <od...@odi.ch>.
Pankaj,
BASIC auth authenticates only a request.
NTLM auth however authenticates a whole connection!
So if the connection is reused no further authentication will be
requested. That's what you are seeing. If you want to authenticate each
request, you must make sure that the connection is closed after the
request. You can achieve this by disabling connection pooling:
new HttpClient(new SimpleHttpConnectionManager(true));
Cheers
Ortwin
Pankaj Arora wrote:
>
>
> ________________________________
>
> From: Pankaj Arora
> Sent: Thursday, May 17, 2007 4:24 PM
> To: 'httpcomponents-dev-info@jakarta.apache.org';
> 'httpcomponents-dev-faq@jakarta.apache.org'
> Subject: HttpClient authentication problem.
>
>
> Hi,
> I am using Http Client to authenticate to IIS web Server for doing NTLM
> authentication. Here's the description of sample codes I am using:
>
>
> Program1 :: This code create 2 state,method,host configuration and use a
> single instance of httpClient to execute method. Please not that in
> first go I give the correct credentials for NTLM authentication and in
> the second go I give the wrong credentials. In the response I observe
> that I get http code 200 and in second go I don't even see
> authentication happening when data is captured over ethereal.
>
> Program2:: This code also create 2 state,method,host configuration but
> use separate instance of httpClient to execute method. Please not that
> in first go I give the correct credentials for NTLM authentication and
> in the second go I give the wrong credentials. In the response I observe
> that I get http code 200 and in second go I get response code as 401.
>
> The problem is I want to use single instance of HttpClient and also want
> that session info is not maintained over the requests. Simply speaking I
> want behavior 2 to happen when their is single instance of HttpClient.
> Is there a way to do this?
>
>
>
> Code and response received from server for reference.
>
> Program1:
> ________________________________________________________________________
> ___________________________________________________________
> // Create an instance of HttpClient.
> HttpClient client1 = new HttpClient();
> HttpMethod _method1 = new GetMethod(url);
> HttpState _httpState1 = new HttpState();
> HostConfiguration hostConfig1 = new HostConfiguration();
> UsernamePasswordCredentials credentials1;
> credentials1 = new
> NTCredentials("administrator","password","host","domain");
>
> AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
>
> _httpState1.setCredentials(authScope1,credentials1);
> hostConfig1.setHost("host"port);
>
> try {
> // Execute the method.
> int statusCode =
> client1.executeMethod(hostConfig1,_method1,_httpState1);
>
> System.out.println("Status code :" + statusCode);
> if (statusCode != HttpStatus.SC_OK) {
> System.err.println("Method failed: " + _method1.getStatusLine()
> + "StatusCode:" + statusCode);
> }
>
> // Read the response body.
> byte[] responseBody = _method1.getResponseBody();
>
>
> Header[] responseHeaders = _method1.getResponseHeaders();
> // Header header;
>
> System.out.println("----------------------------------------------------
> -----------------------------------");
> for( Header header : responseHeaders){
> System.out.println("Headers is " + header.getName() + "and the value
> is :" + header.getValue());
> }
>
>
> HttpMethod _method2 = new GetMethod(url);
> HttpState _httpState2 = new HttpState();
> HostConfiguration hostConfig2 = new HostConfiguration();
> UsernamePasswordCredentials credentials2;
> credentials2 = new NTCredentials("administrator","wrong
> password","host","domain");
>
> AuthScope authScope2 = new AuthScope("host",port,"host","domain");
>
> _httpState2.setCredentials(authScope2,credentials2);
> hostConfig2.setHost("host",port);
> _httpState2.setCredentials(authScope2,credentials2);
> statusCode =
> client1.executeMethod(hostConfig2,_method2,_httpState2);
>
> System.out.println("Status code :" + statusCode);
> if (statusCode != HttpStatus.SC_OK) {
> System.err.println("Method failed: " + _method2.getStatusLine()
> + "StatusCode:" + statusCode);
> }
>
> // Read the response body.
> responseBody = _method2.getResponseBody();
> responseHeaders = _method2.getResponseHeaders();
> // Header header;
>
> System.out.println("----------------------------------------------------
> -----------------------------------");
> for( Header header : responseHeaders){
> System.out.println("Headers is " + header.getName() + "and the value
> is :" + header.getValue());
> }
> ________________________________________________________________________
> __________________________________________________________________
>
> Response 1:
> ________________________________________________________________________
> ___________________________________________________________________
> May 17, 2007 2:40:17 AM
> org.apache.commons.httpclient.auth.AuthChallengeProcessor
> selectAuthScheme
> INFO: ntlm authentication scheme selected
> Status code :200
> ------------------------------------------------------------------------
> ---------------
> Headers is Content-Lengthand the value is :51
> Headers is Content-Typeand the value is :text/html
> Headers is Last-Modifiedand the value is :Sat, 14 Apr 2007 08:44:30 GMT
> Headers is Accept-Rangesand the value is :bytes
> Headers is ETagand the value is :"5cc42b1e717ec71:11d9"
> Headers is Serverand the value is :Microsoft-IIS/6.0
> Headers is Dateand the value is :Thu, 17 May 2007 09:30:53 GMT
> Status code :200
> ------------------------------------------------------------------------
> ---------------
> Headers is Content-Lengthand the value is :51
> Headers is Content-Typeand the value is :text/html
> Headers is Last-Modifiedand the value is :Sat, 14 Apr 2007 08:44:30 GMT
> Headers is Accept-Rangesand the value is :bytes
> Headers is ETagand the value is :"5cc42b1e717ec71:11d9"
> Headers is Serverand the value is :Microsoft-IIS/6.0
> Headers is Dateand the value is :Thu, 17 May 2007 09:30:53 GMT
> ________________________________________________________________________
> ____________________________________________________________
>
>
> Program2:
> ________________________________________________________________________
> ______________________________________________________________
>
> // Create an instance of HttpClient.
> HttpClient client1 = new HttpClient();
> HttpMethod _method1 = new GetMethod(url);
> HttpState _httpState1 = new HttpState();
> HostConfiguration hostConfig1 = new HostConfiguration();
> UsernamePasswordCredentials credentials1;
> credentials1 = new
> NTCredentials("administrator","password","host","domain");
>
> AuthScope authScope1 = new AuthScope("host",port,domain,"NTLM");
>
> _httpState1.setCredentials(authScope1,credentials1);
> hostConfig1.setHost("host"port);
>
> try {
> // Execute the method.
> int statusCode =
> client1.executeMethod(hostConfig1,_method1,_httpState1);
>
> System.out.println("Status code :" + statusCode);
> if (statusCode != HttpStatus.SC_OK) {
> System.err.println("Method failed: " + _method1.getStatusLine()
> + "StatusCode:" + statusCode);
> }
>
> // Read the response body.
> byte[] responseBody = _method1.getResponseBody();
>
>
> Header[] responseHeaders = _method1.getResponseHeaders();
> // Header header;
>
> System.out.println("----------------------------------------------------
> -----------------------------------");
> for( Header header : responseHeaders){
> System.out.println("Headers is " + header.getName() + "and the value
> is :" + header.getValue());
> }
>
> HttpClient client2 = new HttpClient();
> HttpMethod _method2 = new GetMethod(url);
> HttpState _httpState2 = new HttpState();
> HostConfiguration hostConfig2 = new HostConfiguration();
> UsernamePasswordCredentials credentials2;
> credentials2 = new NTCredentials("administrator","wrong
> password","host","domain");
>
> AuthScope authScope2 = new AuthScope("host",port,"host","domain");
>
> _httpState2.setCredentials(authScope2,credentials2);
> hostConfig2.setHost("host",port);
> _httpState2.setCredentials(authScope2,credentials2);
> statusCode =
> client2.executeMethod(hostConfig2,_method2,_httpState2);
>
> System.out.println("Status code :" + statusCode);
> if (statusCode != HttpStatus.SC_OK) {
> System.err.println("Method failed: " + _method2.getStatusLine()
> + "StatusCode:" + statusCode);
> }
>
> // Read the response body.
> responseBody = _method2.getResponseBody();
> responseHeaders = _method2.getResponseHeaders();
> // Header header;
>
> System.out.println("----------------------------------------------------
> -----------------------------------");
> for( Header header : responseHeaders){
> System.out.println("Headers is " + header.getName() + "and the value
> is :" + header.getValue());
> }
> ________________________________________________________________________
> __________________________________________________________________
>
> Response 2:
> ________________________________________________________________________
> ___________________________________________________________________
> May 17, 2007 3:43:07 AM
> org.apache.commons.httpclient.auth.AuthChallengeProcessor
> selectAuthScheme
> INFO: ntlm authentication scheme selected
> Status code :200
> ------------------------------------------------------------------------
> ---------------
> Headers is Content-Lengthand the value is :51
> Headers is Content-Typeand the value is :text/html
> Headers is Last-Modifiedand the value is :Sat, 14 Apr 2007 08:44:30 GMT
> Headers is Accept-Rangesand the value is :bytes
> Headers is ETagand the value is :"5cc42b1e717ec71:11e1"
> Headers is Serverand the value is :Microsoft-IIS/6.0
> Headers is Dateand the value is :Thu, 17 May 2007 10:33:42 GMT
> May 17, 2007 3:43:08 AM
> org.apache.commons.httpclient.auth.AuthChallengeProcessor
> selectAuthScheme
> INFO: ntlm authentication scheme selected
> May 17, 2007 3:43:08 AM org.apache.commons.httpclient.HttpMethodDirector
> processWWWAuthChallenge
> INFO: Failure authenticating with NTLM <any realm>@vm3-ntlm-01:8589
> Status code :401
> Method failed: HTTP/1.1 401 UnauthorizedStatusCode:401
> ------------------------------------------------------------------------
> ---------------
> Headers is Content-Lengthand the value is :1539
> Headers is Content-Typeand the value is :text/html
> Headers is Serverand the value is :Microsoft-IIS/6.0
> Headers is WWW-Authenticateand the value is :Negotiate
> Headers is WWW-Authenticateand the value is :NTLM
> Headers is Dateand the value is :Thu, 17 May 2007 10:33:42 GMT
> ________________________________________________________________________
> _______________________________________________________________
>
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org