Ok, to add yet another dimension to this... When I use IE with the configured proxy settings, and I run a packet capture at the moment I select "Attach File" in the Yahoo Mail compose message window, I capture the aforementioned POST method, which eventually fails or hangs etc. When I use Firefox with manually configured proxy settings (NOT the "use system settings" option) and I perform the same packet capture at the same point, I capture nothing to/from squid and the file is attached successfully. When I use Firefox with the "use system settings" proxy config, it behaves like IE above and fails. I know this is significant, but at this point I'm not sure what it means. Hank > Date: Mon, 6 Feb 2012 20:00:24 +1300 > From: squid3@xxxxxxxxxxxxx > To: squid-users@xxxxxxxxxxxxxxx > Subject: Re: POST method when using squid_kerb_auth and sending Yahoo mail attachment > > 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 >