Double requests being sent to server with auth

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Upload a form to any auth-enabled server
2.
3.

What is the expected output? What do you see instead?
One would expect one HEAD to get the 401, then another HEAD with the proper 
credentials, and then one POST to do the upload. Instead two POSTs are being 
sent. So evidently the credentials are not being sent preemptively.

What version of the product are you using? On what operating system?
1.1.7RC, Android 2.3.4

Please provide any additional information below.

Original issue reported on code.google.com by tomsm...@gmail.com on 28 Jul 2011 at 3:59

[GoogleCodeExporter]

Fixed with this patch. I think this should be classified as an enhancement.

Original comment by tomsm...@gmail.com on 28 Jul 2011 at 4:02

Attachments:

• diff.diff

[GoogleCodeExporter]

Original comment by wbrune...@gmail.com on 29 Jul 2011 at 12:27

• Added labels: Collect, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

"The patch should probably be changed to do preemptive auth only if the target 
host port is 8443 or 443; what we really want to do is only send credentials if 
the intended scheme is https, but I don't know how to do that."
-- mitch

Original comment by yanokwa on 29 Jul 2011 at 8:46

[GoogleCodeExporter]

This issue was closed by revision 9b24ad8c72e0.

Original comment by carlhart...@gmail.com on 27 Sep 2011 at 9:58

• Changed state: Fixed

[GoogleCodeExporter]

I realized I attached the wrong patch to this. The proper one is attached to 
this message. It includes a new function in WebUtils.java.

I'm not quite sure I understand Mitch's comment above. If I did perhaps I could 
suggest something.

Original comment by tomsm...@gmail.com on 20 Oct 2011 at 3:12

Attachments:

• preemptive-auth.patch

[GoogleCodeExporter]

The issue with your patch is that you don't check that the communications 
channel is running within an HTTPS pipe before proactively attaching the 
username and password.  Basic auth credentials are sent in plaintext (base64 
encoded). By not first ensuring you are operating within an HTTPS pipe, you 
have ended up broadcasting your username and password, in plaintext, to the 
world.

Not sure what fix carl and yaw implemented, but a simple check to mitigate this 
erroneous wide disclosure of username and password is to first ensure that the 
server is being contacted on port 443 or 8443; those are, by convention, the 
https and non-privileged alternate https ports for a webserver.

Original comment by mitchellsundt@gmail.com on 20 Oct 2011 at 5:12

[GoogleCodeExporter]

I understand what you're saying now. I'll take a crack at this and get back to 
y'all.

Original comment by tomsm...@gmail.com on 20 Oct 2011 at 6:42

[GoogleCodeExporter]

Original comment by yanokwa on 20 Oct 2011 at 8:47

• Changed state: Accepted

[GoogleCodeExporter]

I think a change accomplishing this was checked into the code base and is 
already in the mainline.

Original comment by mitchellsundt@gmail.com on 20 Oct 2011 at 8:54

[GoogleCodeExporter]

I believe that was on a different but related issue. I have checked the trunk 
and this issue still exists. My patch fixes it, but your earlier comment still 
applies and I will address it when I get time.

Original comment by tomsm...@gmail.com on 21 Oct 2011 at 2:12

[GoogleCodeExporter]

Original comment by yanokwa on 25 May 2012 at 8:10