-
Notifications
You must be signed in to change notification settings - Fork 198
Pages requiring authorisation do not work on Safari #132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Any help from safari users on what's going on here would be helpful. We're following the http digest spec as far as we know. |
What we really need is a log of the HTTP request(s) that Safari sends us when this happens. |
This is the HTTP request header that I apparently send for
Does this help in any way? |
@christiaanb thanks. And is that the only request it makes? Given that request, the server will respond asking to authorise, e.g. something like:
So then the question is what it does in response. It is supposed to prompt the user for the password and resend with the appropriate credentials (using http digest auth). |
A more complete version:
|
Just to say that this is a rather annoying bug! |
Here is the best data I can extract from the Safari debugger: Request headers:
Response headers:
The nastiest thing about this bug is that it means any authenticated page on hackage cannot be accessed on an iPad or iPhone, since these don't have the option of installing a different browser. |
@hesselink You can install other browsers (including Chrome) on iOS devices. You just cannot make it the default browser (for opening attachments and the like). Nevertheless, I would greatly appreciate if anybody had any idea what is going wrong here. |
You are right. I assumed it wouldn't help, as they use the same underlying engine, but I just tested Chrome, and I could log in on hackage using it. That gives us a workaround, at least. As for the underlying cause, I've done a bit of googling, but haven't found anything definitive. There seems to be a lot of grumbling about differing implementations of digest authentication in browsers and bugs relating to it, though. So perhaps tweaking some of the parameters, or changing of the quoting, could shed some light on it. |
I'm not sure what the TODO meant, but 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 haskell#132.
We now offer 'qop="auth"', because without it, authentication in Safari fails immediately. With the field set to auth, authentication seems to work in the latest Firefox, Safari, Chrome and Internet Explorer. However, the HTTP package as used in cabal-install has a bug where it send 'qop="auth"' without an 'nc' or 'cnonce' field. So we are lenient: when these fields are not present, we fall back to no qop. Fixes haskell#132. [1] haskell/HTTP#54
Every hackage page that requires authorisation, such as
http://hackage.haskell.org/packages/candidates/
orhttp://hackage.haskell.org/package/<PACKAGE>/maintain
gives me the messageNo authorization provided
on Safari.Using Chrome I do however get the prompt for username/password and everything works perfectly.
The text was updated successfully, but these errors were encountered: