Fix authentication in Safari.

[hesselink]

@dcoutts: I'm not sure what the TODO meant, perhaps you remember?

An empty qop field makes authentication in Safari fail immediately. With the field set to auth, authentication seems to work in the latest Firefox, Safari, Chrome and Internet Explorer. This is with HTTP 4000.2.10.

Fixes #132, which we're getting asked about a lot on admin@hackage.haskell.org.

[tibbe]

Thanks for the patch. Could you check the Travis CI test failure above please?

[hesselink]

Yes, I'll see if I can fix that, thanks for pointing it out.

[hesselink]

I think I see what the problem is. Now that we set qop to auth, clients are expected to send nc and cnonce fields. But the HTTP package can't send these fields. This is probably what the TODO was referring to. So this means we cannot do digest auth with the HTTP package to the hackage server. But I think cabal still uses basic auth, right? In that case, this would only be a problem with the tests, and nothing else.

[tibbe]

@dcoutts, do we support both auth types or only digest auth?

On Thu, Mar 20, 2014 at 2:07 PM, Erik Hesselink notifications@github.xm233.cnwrote:

I think I see what the problem is. Now that we set qop to auth, clients
are expected to send nc and cnonce fields. But the HTTP package can't
send these fields. This is probably what the TODO was referring to. So this
means we cannot do digest auth with the HTTP package to the hackage server.
But I think cabal still uses basic auth, right? In that case, this would
only be a problem with the tests, and nothing else.

Reply to this email directly or view it on GitHubhttps://github.com//pull/199#issuecomment-38164100
.

[dcoutts]

We only offer digest auth (however if clients pre-emptively send basic auth then we do accept it).

So a properly functioning client that gets prompted for authentication will only be offered digest and should only respond with digest auth.

[dcoutts]

Perhaps we can make the code do this conditionally for safari. Using no qop should be ok according to the standard (iirc), it's the older digest standard, but the newer one the introduces qop (I think) still says it's ok to leave it out and behave the same as the older standard.

[dcoutts]

Actually, if the HTTP package just ignores the qop then we should be ok. The server can use qop=auth and look for the nc etc as per RFC2617, but if the client is following the older RFC2069 then it'd not send it. RFC2617 says the following about the client sending the qop field:

This directive is optional in order to
preserve backward compatibility with a minimal implementation of
RFC 2069 [6], but SHOULD be used if the server indicated that qop
is supported by providing a qop directive in the WWW-Authenticate
header field.

[dcoutts]

Oh, right, but that's what the TODO was about, that the HTTP package has a totally broken qop=auth impl. It sends qop=auth but does not include the required cnonce etc. We could make the server more forgiving, by treating qop=auth without the other required params as being equiv to no qop directive at all.

Filed as haskell/HTTP#54

[hesselink]

I've amended the fix to fall back to QopNone when the 'nc' or 'cnonce' fields are missing. This fixes the test case (at least locally; let's wait for Travis).

[dcoutts]

Thanks!

[mchakravarty]

Thanks for fixing this! 👍