while waiting to see if op tried my mod to okhttp, i was taking a look
at RFC7616 (which, of course, has been superseded by RFC 7235)
if tl;dnr, skip to bottom.
first, the version of okhttpclient used in our internal libraries, supports
all the methods described in RFC7616 (among which MD5 and SHA-256),
technically, my mod should work in cases where SHA-256 was required.
i also did a version that allows for MD5 (by default) or SHA-256 if that's
what the server wanted. (
@OliverA's wish for an updated okhttp duly noted).
unfortunately, there are no test sites (none that i could find) that allow one
to debug the full process. i found 3 which didn't really put much effort into
implementing the protocol (httpbin.org, among others).
among some interesting statements in RFC7616:
"
both client and server know the username." and "the server need not know
the password" (the authorization protocol deals with that). furthermore,
use of the digest authentication "requires that the authenticating agent (usually
the server) store some data derived from the user's name and password
in a "password file" associated with a given realm." the term password can
refer to, eg, a hash rather than the actual password. without getting into a
longer discussion about this aspect, suffice it to say if you look at a typical
unix password file, you'll see the usernames plus some binary garbage where
the passwords would be. passwords are unknown. in the case of digest
authentication, the client creates a hash of his password based on part of
the server's challenge. the server compares the hash with what it has on
file.
the server "might challenge the client by responding with "401 Unauthorized"
response and include
one or more WWW-Authenticate header fields." in
other words, the client might get a choice of algorithm (which choice has to
be indicated in the response to the server).
the specification indicates that SHA2-256 is must be implemented by a
conforming client. MD5 is also required for backward compatibility
lastly, "if digest authentication is being used, it should be over a secure
channel like https".
----------------------------------------------------------------------------------------------------
i found the most interesting statement related to the server's having prior
knowledge of the username and password (or hash). has the op carried
out Shelly.SetAuth at some point? does the device already have the
username and password? if not, then logging in, whether by any means,
would fail.