Nonstandard digest auth implementation causes issues with MK3

[the-ress]

The library doesn't include the algorithm and opaque fields in Authorization header as required by the spec.

Authorization: Digest username="[redacted]", realm="Administrator", nonce="[redacted]", uri="/api/version", response="[redacted]"

This causes PrusaLink on MK3 return 401 and log poorwsgi[647]: ERROR: Digest: algorithm None not equal to MD5-sess {error():215}.

I'd suggest replacing the digest auth implementation with a proven existing library.

Edit: httpx looks like a good candidate. It's being used by the generic camera HA integration for example.

[geekofweek]

I've been poking at this for a couple of hours and was finding similar results. It fails trying to validate the endpoint and kicks back a InvalidAuth.

I think a lot of the focus has erroneously been around the API version for the MK3 implementation because of the wonky version number. That really doesn't have any implication since all of the v1 API endpoints have been there for sometime and work exactly the same. On the previous library just removing the API version check was enough for it to function just fine.

The RESTful sensor utilizes httpx as well, which is what my fallback has been for the MK3 to hit the same v1 API endpoints to recreate the native integration on the MK3.

[the-ress]

I've been poking at it for an hour now and it won't be as easy as I thought. After switching to httpx, MK3 works fine, but MK4 breaks.

It looks like, MK3 requires the algorithm field, but MK4 returns 400 if it's present. But when I patched httpx not to send it, I'm still getting 401. I don't yet know why.

Here's my current code btw: the-ress@4aa1f3b

As for the API version, I patched my PrusaLink so it returns 2.0.0 and it's been working well until I upgraded to HA 2024.1.0 today.

[the-ress]

The 401 I was getting from MK4 is caused by a bug in httpx:

https://github.com/encode/httpx/blob/ebc1393c5cf6430e3027bdb724368a9d6e3429ef/httpx/_auth.py#L283

HA1 in the hash is duplicated and it shouldn't be - on lines 283 and 293. (Also mentioned in encode/httpx#2788 (comment))

[geekofweek]

I haven't been able to make much progress on wrapping my head around the httpx bug. From that thread it doesn't look like that specific issue was addressed only the cookie on retired requests. I'm not sure if there is a workaround for this specific issue or if something needs to be addressed upstream with httpx or with the PrusaLink implementation on the MK3 or MK4. MK4 would be more difficult being it's a firmware implementation.

FYI I have both MK3 and MK4 printers to test against. I've also had issues using a restFUL sensor on the MK4 which also uses httpx.

[the-ress]

I spent a few evenings digging through MK4 firmware code, and I fixed the algorithm issue, I think (prusa3d/Prusa-Firmware-Buddy#3665).

Now I'm going to create a httpx PR to fix the hash thing (edit: here it is encode/httpx#3045), and then it should be usable for both MK3 and MK4 (and XL, MINI).

Pyprusalink will also need some workaround so it still works with MK4 at least until a new firmware with the fix is released (assuming they'll merge it).

I have both MK3 and MK4 too.

I've also had issues using a restFUL sensor on the MK4 which also uses httpx.

That checks out. Those two issues should be occurring there too.