-
Notifications
You must be signed in to change notification settings - Fork 18
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
Improve challenge parsing #16
base: master
Are you sure you want to change the base?
Conversation
It is allowed to provide multiple authentication schemes with optional challenges in the WWW-Authenticate headers. This fixes that it always took the first scheme, and thus failed on a header such as: WWW-Authenticate: NTLM, Digest .... Also frameworks such as Faraday group multiple WWW-Authenticate headers in a response, for example WWW-Authenticate: Digest ... WWW-Authenticate: NTLM into: WWW-Authenticate: Digest ..., NTLM so there is a single way of retrieving header data. This commit changes the parser to pick out only the digest challenge part and the authentication parameters until it encounters another scheme (if any).
This allows for HTTP servers to provide headers where the challenge parameter values are unquoted or when there is no spacing after the parameter separator.
It might also be a good idea to throw |
I think an exception that is understandable is better than NoMethodError for undiagnosable reasons |
This also includes the case where there is no Digest authentication in the auth header at all. Adds a small remark about this to the documentation of Net::HTTP::DigestAuth#auth_header.
I added a commit that raises a |
Please accept this pull request, I believe it addresses |
This branch improves and fixes the parsing of the challenge in the header. It fixes a crash if there are multiple authentication schemes in the header and it adds some robustness for HTTP servers that are not completely compliant with RFC 2617.
Parsing/regexps are inspired by RFC 2617: https://tools.ietf.org/html/rfc2617#section-3.2.1.