On 6/02/2012 5:31 p.m., Hank Disuko wrote:
Thanks Amos,
What's happening is quite similar to the details described in the aforementioned Firefox bug filing.
Of course. Authentication in HTTP has a flow of 4+ steps:
1) --> client request
2) <-- server challenge 401 or 407 response
3) --> client request w/ credentials
4) <-- server success/fail response
...
This is the same for all authentication protocols. Possibly with a loop
repeating 3 & 4 until a suitable set of credentials are agreed on or the
client gives up.
* The firefox bug was about firefox not sending "Basic" auth protocol
credentials properly when challenged.
* So far you have been talking around the edges of something that sounds
like a client not sending "Kerberos" auth protocol credentials correctly
when challenged,
or possibly you misconfiguring a Kerberos helper to validate
non-Kerberos credentials.
The user watching gets to see only that the auth worked, a popup
appeared, or the forbidden error page appeared. They are not forced to
see what protocols are in use or how many retries were made.
When the "attach file" function is started in the Yahoo Mail compose message window and a file is selected from the user's desktop filesystem, a new HTTP POST operation is initiated to squid. This is a new tcp session entirely.
This would be step (1) above.
The POST operation is a form served by host sp1.attach.mail.yahoo.com using a Shockwave Flash user-agent - so I'm assuming the browser itself sits this one out. Here's the first little bit of the request, it's followed by form-data such as "filename" and "content-type" etc.
Aha. Now we are getting places. First item is to check whether Shockwave
Flash supports Kerberos protocol which you are requiring of it. Chances
are shockwave does but the applet it is running does not. It is very
common to find web apps which cannot do auth even when SDK like Flash
and Java have long provided API to do all the difficult parts.
POST http://sp1.attach.mail.yahoo.com/ca.f431.mail.yahoo.com/ya/upload_with_cred?-- HTTP/1.1
Accept: text/*
Content-Type: multipart/form-data; boundary=----------cH2ae0gL6KM7ei4ei4ei4Ij5Ij5KM7
User-Agent: Shockwave Flash
Host: sp1.attach.mail.yahoo.com
Content-Length: 719794
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: B=dgrausd7a344r&b=4&d=vku6LippYFR6PRpZokl3s5qyCUJklnhtfiFf&s=pt&i=A6MbHqjIfHzX9QIh5CDC;
Yes definitely a step (1) client request with no credentials.
However the thing to note here is that this POST request is using a
simple HTTP format without the HTTP/1.1 chunked encoding or Expect
features. That is fine but it means that Content-Length bytes of data
MUST be transmitted for the body, regardess of what the server rsponds with.
Squid responds to this initial POST operation with the predictable TCP_DENIED/407 "Cache Access Denied" message:
from access.log:
Sun Feb 5 22:29:16 2012 3 172.16.130.22 TCP_DENIED/407 5626 POST http://sp1.attach.mail.yahoo.com/ca.f431.mail.yahoo.com/ya/upload_with_cred? - NONE/- text/html
HTTP/1.0 407 Proxy Authentication Required
Server: squid/3.1.11
Mime-Version: 1.0
Date: Mon, 06 Feb 2012 03:29:16 GMT
Content-Type: text/html
Content-Length: 5206
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
Vary: Accept-Language
Content-Language: en
Proxy-Authenticate: Negotiate
X-Cache: MISS from localhost
X-Cache-Lookup: NONE from localhost:3128
Via: 1.0 localhost (squid/3.1.11)
Connection: keep-alive
So far everything is perfectly correct.
Squid actually serves up the full "407 Denied" webpage, but it's not presented to the user.
That is correct. Displaying the error page is optional. Being kerberos
authentication it SHOULD be able to locate the Kerberos credentials
silently in the background without bothering the user at all.
Instead, the Yahoo Flash user-agent seems to trample on instead and attempts to send the attachment anyway, without first re-sending the request with the credentials required to access squid.
This is correct. It MUST do so. It has instructed Squid that
"Content-Length: 719794" bytes are following the headers. Squid will
read and discarded it all then the connection will become free for the
keep-alive features to re-use.
I can see the pdf being uploaded to the squid server, but squid just ignores it.
Good. That means Squid is working.
This manifests as a "hanging" upload window to the user.
Maybe, maybe not. Flash is expected to locate credentials after the 407
and repeat the POST request with them attached.
If it cannot locate credentials it is expected to produce some form of
error about that failure.
A non-changing upload window could just mean the app is waiting while
the first POST is transmitted and discarded and the Kerberos credentials
are being located. It may start to display things if it ever gets to the
point of doing a POST with credentials.
I guess I need to know where to look in order to find out why the request is not re-sent using the proper credentials. Is it the Yahoo user-agent? is it the browser?
The Shockwave player or the application running inside it. If either one
does not support your required Negotiate/Kerberos auth (or even auth in
general) it will fail.
Amos
