http request action & digest auth
-
I’m using the HTTP Request action in MSR and need to authenticate against an endpoint that uses HTTP Digest authentication. Now that endpoint was changed to use SHA-256 in digest auth, so I would like to know if MSR supports it, or is it limited to MD5-based digest auth?
-
Have you tried it?
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Have you tried it?
@toggledbits I have, but it's a bit complicated setup (a proxy in between because of earlier problems with x-www-authenticate & www-authenticate headers). Related to Fronius inverter firmware update (some people have discussed this problem e.g. here)
I'm considering using modbus tcp (in home assistant) instead of http request, as this is getting tricky.
-
Well... isn't this interesting... I tried to find a reliable SHA-256 endpoint to test against. Pretty much everything I tried went to MD5. So I wrote my own that I could restrict to a specific hash algorithm, and lo! and behold! I found a bug in the digest-fetch package... if it attempts auth with an algorithm and the server responds with a different algorithm (i.e. what it supports/prefers), it simply re-issues the same request with the prior algorithm rather than trying the server's suggested algorithm. Mind you, this package has been like this for years (like maybe 2019?), and the last big check-in for the package was three years ago and not about this.
So quick and dirty, I wrote a wrapper around it to do the right thing, and it should properly support SHA-256, SHA-512-256, and MD5 (in that order of preference for now). That will be in the next build (soon).
Edit: the fix for this issue was made in build 26143.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Well... isn't this interesting... I tried to find a reliable SHA-256 endpoint to test against. Pretty much everything I tried went to MD5. So I wrote my own that I could restrict to a specific hash algorithm, and lo! and behold! I found a bug in the digest-fetch package... if it attempts auth with an algorithm and the server responds with a different algorithm (i.e. what it supports/prefers), it simply re-issues the same request with the prior algorithm rather than trying the server's suggested algorithm. Mind you, this package has been like this for years (like maybe 2019?), and the last big check-in for the package was three years ago and not about this.
So quick and dirty, I wrote a wrapper around it to do the right thing, and it should properly support SHA-256, SHA-512-256, and MD5 (in that order of preference for now). That will be in the next build (soon).
Edit: the fix for this issue was made in build 26143.
@toggledbits great work, as always!
-
Well... isn't this interesting... I tried to find a reliable SHA-256 endpoint to test against. Pretty much everything I tried went to MD5. So I wrote my own that I could restrict to a specific hash algorithm, and lo! and behold! I found a bug in the digest-fetch package... if it attempts auth with an algorithm and the server responds with a different algorithm (i.e. what it supports/prefers), it simply re-issues the same request with the prior algorithm rather than trying the server's suggested algorithm. Mind you, this package has been like this for years (like maybe 2019?), and the last big check-in for the package was three years ago and not about this.
So quick and dirty, I wrote a wrapper around it to do the right thing, and it should properly support SHA-256, SHA-512-256, and MD5 (in that order of preference for now). That will be in the next build (soon).
Edit: the fix for this issue was made in build 26143.
@toggledbits ...Revisiting this briefly, and a humble request for you to consider.
I'm still struggling with this particular solar inverter that's acting in a non-standard manner (against RFC 7616). Given this behavior, I would like to ask for the following changes to the HTTP request handling:
- If the server returns the header
x-www-authenticate, it would be treated equivalently towww-authenticate - If the server specifies
algorithm="SHA256", it would be interpreted asalgorithm=SHA-256(and there might be even extra whitespaces present, e.g. " SHA256 ")
- If the server returns the header
-
I'll see what can be done later, but this comes from a package I use, not code of my own creation. Despite the bug discovered, if I abandon the external package, I lose years of testing against myriad servers in the wild, so it's a potentially costly trade-off that makes a lot of future work (and frustration, potentially).
