auth: Support digest auth

[wojtekmach]

curl example:

$ curl --fail --user foo:bar --digest https://httpbin.org/digest-auth/auth/foo/bar
{
  "authenticated": true,
  "user": "foo"
}

We should support:

Req.get!("https://httpbin.org/digest-auth/auth/foo/bar", auth: {:digest, "foo", "bar"})

[zachallaun]

@wojtekmach Trying to get my feet a bit wet, so I started thinking through this earlier today and wanted to run my thoughts by you.

Digest auth works first by issuing an unauthenticated request, receiving a 401, and then re-issuing the request with an authentication header setup using information in the 401 response header. Given this, I’d expect this to be implemented as an error step before the retry step.

This digest auth error step would check that:

1. digest was specified in the auth options (as in your description)

2. we’ve received a 401 with the proper header for digest auth

3. we’re not receiving a second error after already attempting to send the digest auth info

If any of those conditions aren’t met, we pass the request/error along to the next step, which would be retry in the default case and can determine whether to retry/etc.

If this seems like the appropriate way to handle it, I have a couple of questions:

1. re: 3) above, the lowest-footprint option is to look at the request headers to determine whether digest auth was used in the request, and if so, to skip the step and let further steps handle it. An alternative is to add private data to the request before digest auth is sent that can be checked later on. I’m inclined towards the first option.

2. any thoughts on whether digest auth deserves a special call-out as something that should not be used except to interact with legacy systems? From doing some research, it appears to be almost strictly less secure than basic auth over https, as it requires that the server store passwords (or something essentially the same) as plain text. It was a superior option to basic auth over http, but with the proliferation of ssl certificates, it has no real place in modern systems, and services that require it may even be considered a “smell”. I don’t think this is reason not to add the feature to a client library, but I thought I’d mention it.

[wojtekmach]

Re A) yup, option 1, except it would be a response step. An error step would be when we didn’t get a response but a socket error and such.

Re B) I think it is actually a good enough reason not to support it. What I mean is, if someone needs it and is willing to do the work then I’d accept a PR but otherwise it is not a high priority. I wanted to have it for completeness but you are totally right it is mostly a thing of the past.

thanks!

[zachallaun]

Sounds good! Agreed that it’s not a priority. It may be something I look to implement anyways as a small exercise. =)