Re: Error in AbstractHTTPDestination.setHeaders, AbstractHTTPDestination.setHeaders

2008-03-21 Thread Glen Mazza
Am Freitag, den 21.03.2008, 01:27 -0400 schrieb Wolf, Chris (IT):
> If I run my service inside a Tomcat-5.5 runtime configured in
> Eclipse-3.2, all works fine. 
> I run the very same code, deployed on Tomcat-5.5 on Linux, I get this
> error.  
> If anyone can suggest something short of debuggin the CXF source, that
> would be 
> great.  I am using 2.0.4. 
> 

If nobody else can answer your question, time to debug the CXF source:

http://www.jroller.com/gmazza/date/20071212

Step #5 would probably be most important for you.

Glen




RE: Error in AbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders

2008-03-21 Thread Wolf, Chris (IT)
Glen,

Thanks again for your help.  I downloaded the source and looked at it 
before going through the laborious task of setting up for remote
debugging.

I can see the the issue is the code in AbstractHTTPDestination always 
assumes the value of the "Authorization" header will always be a base64
encoded "username:password" value -- in my case, we use Siteminder
authentication,
so sometimes the value of the "Authorization" header is just the base64
encoded
username -- without a colon and password, i.e. no ":passw", which
exactly
explains this array index out of bounds exception. 

The workaround is, I'm going to tell my users to log out of Siteminder
and re-authenticate, such that the "Authorization" header always has
both
pieces in the value. 

I would like to present a patch for the case where the "Authorization" 
header value does not contain a colon character, even for "Basic"
type of authentication, but I'm not sure special accomodation would be
made for Siteminder, unelss the RFC for Basic authentication says the
"Authorization" header may contain just an encoded username in certain 
circumstances.

 
-Chris

-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 21, 2008 7:12 AM
To: cxf-user@incubator.apache.org
Subject: Re: Error in
AbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders

Am Freitag, den 21.03.2008, 01:27 -0400 schrieb Wolf, Chris (IT):
> If I run my service inside a Tomcat-5.5 runtime configured in 
> Eclipse-3.2, all works fine.
> I run the very same code, deployed on Tomcat-5.5 on Linux, I get this 
> error.
> If anyone can suggest something short of debuggin the CXF source, that

> would be great.  I am using 2.0.4.
> 

If nobody else can answer your question, time to debug the CXF source:

http://www.jroller.com/gmazza/date/20071212

Step #5 would probably be most important for you.

Glen


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.


RE: Error in AbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders

2008-03-21 Thread Glen Mazza
I've been looking at our Basic Authentication recently--the error
messages have been cryptic in many cases, not providing acceptable
feedback.  

In your case below, we should have a precise error message about an
invalid format in the Authorization header field--not just an NPE of
course.  If you could submit a JIRA for this it would be appreciated,
else I'll try to remember.

I don't think we should make an exception for Siteminder though, because
that might open up a security hole.  Also, Section two of RFC 2617[1]
states:  "To receive authorization, the client sends the userid and
password, separated by a single colon (":") character, within a base64
[7] encoded string in the credentials."  Apparently both username and
password are always needed.  I don't know Siteminder but I would think
they would have an option to always supply a password in order to be RFC
2617 compliant.  If not, please let them know about it.

Thanks,
Glen


[1] http://www.faqs.org/rfcs/rfc2617.html

Am Freitag, den 21.03.2008, 11:30 -0400 schrieb Wolf, Chris (IT):
> Glen,
> 
> Thanks again for your help.  I downloaded the source and looked at it 
> before going through the laborious task of setting up for remote
> debugging.
> 
> I can see the the issue is the code in AbstractHTTPDestination always 
> assumes the value of the "Authorization" header will always be a base64
> encoded "username:password" value -- in my case, we use Siteminder
> authentication,
> so sometimes the value of the "Authorization" header is just the base64
> encoded
> username -- without a colon and password, i.e. no ":passw", which
> exactly
> explains this array index out of bounds exception. 
> 
> The workaround is, I'm going to tell my users to log out of Siteminder
> and re-authenticate, such that the "Authorization" header always has
> both
> pieces in the value. 
> 
> I would like to present a patch for the case where the "Authorization" 
> header value does not contain a colon character, even for "Basic"
> type of authentication, but I'm not sure special accomodation would be
> made for Siteminder, unelss the RFC for Basic authentication says the
> "Authorization" header may contain just an encoded username in certain 
> circumstances.
> 
>  
> -Chris
> 
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 21, 2008 7:12 AM
> To: cxf-user@incubator.apache.org
> Subject: Re: Error in
> AbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders
> 
> Am Freitag, den 21.03.2008, 01:27 -0400 schrieb Wolf, Chris (IT):
> > If I run my service inside a Tomcat-5.5 runtime configured in 
> > Eclipse-3.2, all works fine.
> > I run the very same code, deployed on Tomcat-5.5 on Linux, I get this 
> > error.
> > If anyone can suggest something short of debuggin the CXF source, that
> 
> > would be great.  I am using 2.0.4.
> > 
> 
> If nobody else can answer your question, time to debug the CXF source:
> 
> http://www.jroller.com/gmazza/date/20071212
> 
> Step #5 would probably be most important for you.
> 
> Glen
> 
> 
> NOTICE: If received in error, please destroy and notify sender. Sender does 
> not intend to waive confidentiality or privilege. Use of this email is 
> prohibited when received in error.