hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander A. Smith" <smit...@sericontech.com>
Subject Re: Android Basic Authentication - the failure case
Date Wed, 30 Jul 2014 15:16:04 GMT
Oleg, thank you for your help, you saved me many hours of debugging.
Problem has been fixed and updated in JIRA.


On Wed, Jul 30, 2014 at 10:49 AM, Oleg Kalnichevski <olegk@apache.org>
wrote:

> On Wed, 2014-07-30 at 10:44 -0400, Sander A. Smith wrote:
> > Yes, just verified. We need to use Base64.NOWRAP instead of
>  Base64.DEFAULT.
> >
>
> Many thanks for confirming the cause of the problem. Could you please
> add this comment to the ticket for the record?
>
> Oleg
>
> >
> > On Wed, Jul 30, 2014 at 10:08 AM, Sander A. Smith <
> smithsa@sericontech.com>
> > wrote:
> >
> > > Oh ok, I was looking at it wrong. The problem really is a single LF
> added
> > > unnecessarily. Looks like the culprit is the BASE64 encoder which for
> some
> > > reason puts a LF at the end automatically. I think that it should be
> Base64.NOWRAP
> > > instead of  Base64.DEFAULT.
> > >
> > >
> > > On Wed, Jul 30, 2014 at 9:27 AM, Oleg Kalnichevski <olegk@apache.org>
> > > wrote:
> > >
> > >> On Wed, 2014-07-30 at 09:08 -0400, Sander A. Smith wrote:
> > >> > Thanks Oleg, I've opened a bug.
> > >> >
> > >> > I think I disagree with you about the possible cause. I understand
> that
> > >> > Android is using a built in Base64 encoder instead of CC, but the
> > >> encoding
> > >> > of the authentication data is happening correctly. What isn't
> happening
> > >> > correctly is the sequence of CR/LF that surrounds it.
> > >> >
> > >> >
> > >>
> > >> You are very welcome to disagree, but I am almost certain the culprit
> is
> > >> this bit in BasicSchemeHC4 that pads base64-coded creds with LF.
> > >>
> > >> ---
> > >>         final byte[] base64password = Base64.encode(
> > >>                 EncodingUtils.getBytes(tmp.toString(), charset),
> > >>                 Base64.DEFAULT);
> > >> ---
> > >>
> > >> Oleg
> > >>
> > >> [1]
> > >>
> > >>
> http://svn.apache.org/repos/asf/httpcomponents/httpclient-android/branches/4.3.3-android/src/main/java/org/apache/http/impl/auth/BasicSchemeHC4.java
> > >>
> > >> > On Wed, Jul 30, 2014 at 5:01 AM, Oleg Kalnichevski <
> olegk@apache.org>
> > >> wrote:
> > >> >
> > >> > > On Tue, 2014-07-29 at 23:12 -0400, Sander A. Smith wrote:
> > >> > > > I'm writing an Android app and am using the HttpClient library
> for
> > >> > > Android
> > >> > > > for all of the communication to the outside world. I've
also
> taken
> > >>  the
> > >> > > > guts of the app and written a Java main so that I can run
from
> the
> > >> > > command
> > >> > > > line using the regular library.
> > >> > > >
> > >> > > > Everything runs beautifully except for one thing: I need
to do
> Basic
> > >> > > > Authentication, and the two platforms, Android and CLI react
> > >> differently
> > >> > > in
> > >> > > > the failure case. If Basic Authentication succeeds (e.g.
the
> correct
> > >> > > > password is used) things run fine. However, in the case
where an
> > >> > > incorrect
> > >> > > > password is used I get a 401 on CLI (correct), but with
the
> Android
> > >> > > library
> > >> > > > I'm getting an exception thrown.
> > >> > > >
> > >> > > > I've debugged enough to watch what goes over the wire.
> > >> > > >
> > >> > > > When I run CLI I see this:
> > >> > > >
> > >> > > >  http-outgoing-4 >> "GET / HTTP/1.1[\r][\n]"
> > >> > > >  http-outgoing-4 >> "User-Agent: xxx"
> > >> > > >  http-outgoing-4 >> "Host: 192.168.1.1[\r][\n]"
> > >> > > >  http-outgoing-4 >> "Connection: Keep-Alive[\r][\n]"
> > >> > > >  http-outgoing-4 >> "Accept-Encoding: gzip,deflate[\r][\n]"
> > >> > > >  http-outgoing-4 >> "Authorization: Basic
> YWRtaW46YWRtaW4=[\r][\n]"
> > >> > > >  http-outgoing-4 >> "[\r][\n]"
> > >> > > >  http-outgoing-4 << "HTTP/1.0 401 Unauthorized[\r][\n]"
> > >> > > >
> > >> > > > Running on Android shows this:
> > >> > > >
> > >> > > >  http-outgoing-4 >> "GET / HTTP/1.1[\r][\n]"
> > >> > > >  http-outgoing-4 >> "User-Agent: xxx"
> > >> > > >  http-outgoing-4 >> "Host: 192.168.1.1[\r][\n]"
> > >> > > >  http-outgoing-4 >> "Connection: Keep-Alive[\r][\n]"
> > >> > > >  http-outgoing-4 >> "Accept-Encoding: gzip,deflate[\r][\n]"
> > >> > > >  http-outgoing-4 >> "Authorization: Basic YWRtaW46YWRtaW4=[\n]"
> > >> > > >  http-outgoing-4 >> "[\r][\n]"
> > >> > > >  http-outgoing-4 >> "[\r][\n]"
> > >> > > >  http-outgoing-4 << "end of stream"
> > >> > > >  http-outgoing-4: Close connection
> > >> > > >
> > >> > > >
> > >> > > > It appears that on Android the sequence of carriage returns
and
> line
> > >> > > feeds
> > >> > > > is not being sent properly, and the server is getting confused.
> > >> > > >
> > >> > >
> > >> > > This looks like an Android specific bug (HttpClient port for
> Android
> > >> > > makes use of Base64 encoding provided by the platform instead
of
> > >> Commons
> > >> > > Codec used by the stock version). Please raise a JIRA for this
> defect.
> > >> > >
> > >> > > Oleg
> > >> > >
> > >> > > > It's also worth noting that when the correct password is
being
> > >> sent, the
> > >> > > > identical information is sent over the wire, but in both
cases,
> an
> > >> HTTP
> > >> > > 200
> > >> > > > is returned.
> > >> > > >
> > >> > > > So what's going on here? Why is behavior different on 2
> different
> > >> > > > platforms? Is there a bug in the Android library?
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> ---------------------------------------------------------------------
> > >> > > To unsubscribe, e-mail:
> httpclient-users-unsubscribe@hc.apache.org
> > >> > > For additional commands, e-mail:
> httpclient-users-help@hc.apache.org
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > >> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > Sander A. Smith
> > > President
> > >
> > > Sericon Technology Inc.
> > > 71 Marquette Ave.
> > > Toronto, Ontario M6A 1X8
> > > (416)781-3988
> > >
> > > Link to me on LinkedIn
> > > http://www.linkedin.com/in/sandersmith
> > >
> > > Learn about the dangers of home routers and how you can protect
> yourself
> > > http://www.RouterCheck.com
> > >
> > > http://www.sericontech.com
> > >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>


-- 
Sander A. Smith
President

Sericon Technology Inc.
71 Marquette Ave.
Toronto, Ontario M6A 1X8
(416)781-3988

Link to me on LinkedIn
http://www.linkedin.com/in/sandersmith

Learn about the dangers of home routers and how you can protect yourself
http://www.RouterCheck.com

http://www.sericontech.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message