DO NOT REPLY [Bug 15297] - [HttpClient] Authenticator() - ability to perform alternate authentication

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15297

[HttpClient] Authenticator() - ability to perform alternate authentication





--- Additional Comments From [EMAIL PROTECTED]  2004-01-14 21:05 ---
>  - Should HttpMethodDirector have it's own version of the auth defaults?  
> It seems like this should be left to the params.

I did not feel like giving users the possibility to mess around with the default
authentication preferences to avoid their misuse. Therefore I wanted to keep the
DEFAULT_AUTH_PREFS private. On the other hand I do agree that HttpClientParams
or AuthPolicy would be a better home for auth defaults.

>  - When new schemes are added, they will have to be added to the 
> AuthPolicy.AUTH_SCHEME_PRIORITY param in order to work.  
> This should probably be documented in AuthPolicy.registerAuthScheme().

Good point. I just realised that this is quite lousy. I think auth defaults
should be derived from the AuthPolicy. I'll try to come up with a better solution. 

A new patch to follow.

Thanks, Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Redirect not working

[Oleg Kalnichevski]

Darrell,
In computing things rarely happen by the Lord's will. The redirect
location must be communicated with the HTTP response one way or another.
You should be able to see what exactly gets transmitted across the wire
by using an HTTP traffic sniffer or by activating the wire/debug logging
in HttpClient. See the HttpClient logging guide for details


If you post the wire log, you might be able to explain why you are
having these problems with redirects

Oleg

On Wed, 2004-01-14 at 19:45, Darrell Bechtel wrote:
> Hi all,
> 
> I have 2 problems I am stuck on. The first is when sending my parameters
> using the postMethod I can retrieve the cookie but the redirect being
> captured with the location key is truncated. All I am getting is
>  http://pub.supercom.ca/ , which should have
> 
> /web/dealprom.nsf/DealerAccess?OpenPage&Login added to the end. I am
> 
> not sure this is a bug or not. The other problem is when using mozilla I am
> using a header plugin to capture all the headers and the browser is
> redirected to the previous site after that the browser is redirected again
> but no location key is in the header and I am unable to detect how the
> browser knows to redirect.
> 
> thanks for any info that may solve these problems 
> 
>  
> 
> Darrell Bechtel B.G.S., MSCE
> Computer Sales / Technical Support
> www.csdepot.com
> 583 King St. N.
> Waterloo, ON
> N2V 2E5
> (519) 747-5423 
> 
>  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26139] - Memory leak in MultiThreadedHttpClient caused by bad .equals()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26139

Memory leak in MultiThreadedHttpClient caused by bad .equals()





--- Additional Comments From [EMAIL PROTECTED]  2004-01-14 19:37 ---
I was experiencing this while using the GetMethod(String) constructor, which
calls the HttpMethodBase constructor, which constructs a new HostConfiguration
each time.

I _think_ that the multithreaded client won't work properly unless you use
separate new GetMethods like this.

Anyway, a usage like this would break unless equals() was added.  I vote #2, 3
where possible.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26139] - Memory leak in MultiThreadedHttpClient caused by bad .equals()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26139

Memory leak in MultiThreadedHttpClient caused by bad .equals()





--- Additional Comments From [EMAIL PROTECTED]  2004-01-14 19:29 ---
Hi Jesse,

If the ProtocolSocketFactory does not implement equals, the object identity is used.  
In most cases 
this has worked, since the socket factories are usually singletons.  After looking at 
the code 
though, it is possible that more than one instance of DefaultProtocolSocketFactory and 
SSLProtocolSocketFactory could be created.  It seems that we have a couple of options 
here to fix 
this:

 - change Protocol to not rely on ProtocolSocketFactory.equals().
 - add equals methods to the socket factories
 - ensure that the socket factories are singletons

My preference is to do #2&3.  What do others think?

Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 15297] - [HttpClient] Authenticator() - ability to perform alternate authentication

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15297

[HttpClient] Authenticator() - ability to perform alternate authentication





--- Additional Comments From [EMAIL PROTECTED]  2004-01-14 19:10 ---
Hi Oleg,

A few comments:

 - Should HttpMethodDirector have it's own version of the auth defaults?  It seems 
like this should 
be left to the params.
 - When new schemes are added, they will have to be added to the 
AuthPolicy.AUTH_SCHEME_PRIORITY param in order to work.  This should probably be 
documented 
in AuthPolicy.registerAuthScheme().

Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Redirect not working

[Darrell Bechtel]

Hi all,

I have 2 problems I am stuck on. The first is when sending my parameters
using the postMethod I can retrieve the cookie but the redirect being
captured with the location key is truncated. All I am getting is
 http://pub.supercom.ca/ , which should have

/web/dealprom.nsf/DealerAccess?OpenPage&Login added to the end. I am

not sure this is a bug or not. The other problem is when using mozilla I am
using a header plugin to capture all the headers and the browser is
redirected to the previous site after that the browser is redirected again
but no location key is in the header and I am unable to detect how the
browser knows to redirect.

thanks for any info that may solve these problems 

 

Darrell Bechtel B.G.S., MSCE
Computer Sales / Technical Support
www.csdepot.com
583 King St. N.
Waterloo, ON
N2V 2E5
(519) 747-5423 

 

DO NOT REPLY [Bug 26139] New: - Memory leak in MultiThreadedHttpClient caused by bad .equals()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26139

Memory leak in MultiThreadedHttpClient caused by bad .equals()

   Summary: Memory leak in MultiThreadedHttpClient caused by bad
.equals()
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: HttpClient
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Note: I have '2.0 release candidate 1'; I'm not sure which version this
translates into.  The bug is definitely present in the current source.

MultiThreadedHttpClient uses the following code:

// Look for a list of connections for the given config
HostConnectionPool listConnections = (HostConnectionPool) 
mapHosts.get(hostConfiguration);
if (listConnections == null) { 
// First time for this config
listConnections = new HostConnectionPool();
listConnections.hostConfiguration = hostConfiguration;
mapHosts.put(hostConfiguration, listConnections);
}


The hash map relys on HostConfiguration's .equals() to resolve equality &
determine if there is a mapping for the configuration.

HostConfiguration has the following in it's .equals() method:

if (!protocol.equals(config.getProtocol())) {
return false;
}

. . . and Protocol has:

if (obj instanceof Protocol) {

Protocol p = (Protocol) obj;

return (
defaultPort == p.getDefaultPort()
&& scheme.equalsIgnoreCase(p.getScheme())
&& secure == p.isSecure()
&& socketFactory.equals(p.getSocketFactory()));

}

However, there is no .equals() method in any of the ProtocolSocketFactory
objects, and there isn't any note in the interface about the necessity of the
.equals() method.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 15297] - [HttpClient] Authenticator() - ability to perform alternate authentication

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15297

[HttpClient] Authenticator() - ability to perform alternate authentication

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-14 17:52 ---
Please review.

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 15297] - [HttpClient] Authenticator() - ability to perform alternate authentication

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15297

[HttpClient] Authenticator() - ability to perform alternate authentication





--- Additional Comments From [EMAIL PROTECTED]  2004-01-14 17:52 ---
Created an attachment (id=9950)
Patch (take 1)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10930] - J2EE FORM authentication (also affects pluggable authentication)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10930

J2EE FORM authentication (also affects pluggable authentication)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-01-14 16:37 ---
If there are any fresh and bright ideas or/and practical suggestions as to how
J2EE authentication can be implemented without causing too much of design
badness, feel free to reopen the bug report. Patches welcome

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10930] - J2EE FORM authentication (also affects pluggable authentication)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10930

J2EE FORM authentication (also affects pluggable authentication)





--- Additional Comments From [EMAIL PROTECTED]  2004-01-14 16:29 ---
Agreed.  This is not something that needs to be fixed.  Form authentication  is just 
like posting 
into any other form.  It is not another kind of HTTP authentication.  This type of 
authentication 
should be handed using PostMethod.

Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10930] - J2EE FORM authentication (also affects pluggable authentication)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10930

J2EE FORM authentication (also affects pluggable authentication)





--- Additional Comments From [EMAIL PROTECTED]  2004-01-14 16:14 ---
I personally do not see an elegant way of implementing the requested feature,
and what is more, do not think that J2EE authentication should be supported by
the stock version of HttpClient at all. 

Authentication logic in HttpClient has undergone several radical changes since
this feature request was filed. The monolithic HttpAuthenticator has been
restructured into smaller, AuthScheme interface implementing modules and
deprecated. Besides, form-based authentication is not a part of HTTP protocol
and should probably better be built on top of HttpClient, instead of being kind
of shoved in.

All that makes me kind of lean towards marking this bug as 'WONTFIX'. What do
you think, guys? Am I being too lazy and unimaginative?

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] deprecated HttpState#isAuthenticationPreemptive no longer has any effect

[Michael Becke]

Yes, it's a hack, but that is what I was thinking as well.  Works for  
me.

Mike

On Jan 14, 2004, at 10:05 AM, Kalnichevski, Oleg wrote:

Mike, I can't think of anything better than this hack. Any better  
ideas?

Index: java/org/apache/commons/httpclient/HttpMethodDirector.java
===
RCS file:  
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/ 
commons/httpclient/HttpMethodDirector.java,v
retrieving revision 1.13
diff -u -r1.13 HttpMethodDirector.java
--- java/org/apache/commons/httpclient/HttpMethodDirector.java	12 Jan  
2004 23:03:12 -	1.13
+++ java/org/apache/commons/httpclient/HttpMethodDirector.java	14 Jan  
2004 14:58:50 -
@@ -195,8 +195,9 @@
 this.params.getConnectionManagerTimeout()
 );
 this.conn.setLocked(true);
-if (this.params.isAuthenticationPreemptive()) {
-
+if (this.params.isAuthenticationPreemptive() ||
+this.state.isAuthenticationPreemptive())
+{
 LOG.debug("Preemptively sending default basic  
credentials");
 this.authState = AUTH_PREEMPTIVE;
 this.authScheme =  
AuthPolicy.getAuthScheme("basic");

-
To unsubscribe, e-mail:  
[EMAIL PROTECTED]
For additional commands, e-mail:  
[EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: HttpClient SSL Helppppp!

[crescent]

Thanksss so much for the help...

Crescent

- Original Message - 
From: "Michael Becke" <[EMAIL PROTECTED]>
To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
Sent: Wednesday, January 14, 2004 11:35 AM
Subject: Re: HttpClient SSL Help!


> Hi Crescent,
>
> This is because the SSL cert on the server is self-signed or signed by
> an unknown certificate authority.  JSSE (the SSL library used by
> HttpClient) by default only trusts those SSL certs that are signed by a
> few authorities (i.e. Verisign, Thawte).  Please take a look at Sun's
> JSSE docs for some more info about this, and how to work around it.
>
> Mike
>
> On Jan 13, 2004, at 8:50 PM, crescent wrote:
>
> > Hi, there
> >
> > While trying to use HttpClient for a SSL application, I encountered an
> > exception, the codes I used were as follows(the URL is made up here):
> >
> > HttpClient client = new HttpClient();
> >  HostConfiguration config = client.getHostConfiguration();
> >  HttpsURL sslURL = new HttpsURL("https://sample.com/test.asp";);
> >  config.setHost(sslURL);
> >  PostMethod post = new PostMethod();
> >
> >  String sXML = "https://sample.com/test.asp";
> >  post.setRequestBody(sXML);
> >  post.setRequestContentLength(sXML.getBytes(sEncoding).length);
> >  post.setRequestHeader("Content-type", "text/xml; charset=Big");
> >  client.executeMethod(client.getHostConfiguration(), post);
> >
> >
> > and the exception occured was:
> >
> >  javax.net.ssl.SSLHandshakeException: unknown certificate
> >
> > my development environment is:
> >
> >  OS : Windows 2000
> >  AP Server : IBM WebSphere 5
> >  JDK : WebSphere JDK
> >
> > appreciate for any suggestions and solutions for the problem.
> >
> > best regards
> >
> > crescent

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PATCH] deprecated HttpState#isAuthenticationPreemptive no longer has any effect

[Kalnichevski, Oleg]

Mike, I can't think of anything better than this hack. Any better ideas?


Index: java/org/apache/commons/httpclient/HttpMethodDirector.java
===
RCS file: 
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodDirector.java,v
retrieving revision 1.13
diff -u -r1.13 HttpMethodDirector.java
--- java/org/apache/commons/httpclient/HttpMethodDirector.java  12 Jan 2004 23:03:12 
-  1.13
+++ java/org/apache/commons/httpclient/HttpMethodDirector.java  14 Jan 2004 14:58:50 
-
@@ -195,8 +195,9 @@
 this.params.getConnectionManagerTimeout() 
 );
 this.conn.setLocked(true);
-if (this.params.isAuthenticationPreemptive()) {
-
+if (this.params.isAuthenticationPreemptive() || 
+this.state.isAuthenticationPreemptive())
+{
 LOG.debug("Preemptively sending default basic credentials");
 this.authState = AUTH_PREEMPTIVE;
 this.authScheme = AuthPolicy.getAuthScheme("basic");


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]