Receiving 403 from https://accounts.myq-cloud.com/api/v6.0/accounts

[livlif2dfullest]

I recently had to switch out my router which gave all new IPs to my entire network, not sure if this is part of the problem, but this is when the issue started occurring. I deleted the MyQ integration, rebooted HA, then re-added, but I still get the same error. I use the same exact credentials to login to the MyQ app on my Android, so I'm not understanding why it's giving me a 403. Is there something else I need to do? I added logging to the myq component in HA to write out the credentials and those are getting passed in correctly to:

myq = await pymyq.login(conf[CONF_USERNAME], conf[CONF_PASSWORD], websession)

yet a MyQError is getting thrown, this is what I logged:
ERROR (MainThread) [homeassistant.components.myq] async_setup_entry, Failed to login due to(MyQError): Error requesting data from https://accounts.myq-cloud.com/api/v6.0/accounts: 403 - Forbidden

Any help is appreciated.

[jonheese]

I'm having the same issue, and it started around the same time. Seems like something changed on the MyQ API end.

[vincebel8]

MyQ implemented CloudFlare, and now a particular User Agent is required in the header of some of the requests during login.

There's some good debugging over here: home-assistant/core#99947

[jonheese]

@vincebel8 Thanks for that! I looked over that thread and it seems like the folks there were having good luck with setting the User-Agent to a random string, but when I tried that (even using the modified pymyq package someone provided in the comments), I wasn't able to get it to work.

Enabling debug logging, I can see that it's using a random string for User-Agent but it's still getting the 403. Is there any reason why the method working for the HA crowd isn't working for other pymyq uses?

Thanks.

[vincebel8]

@jonheese is this the fork you tried? https://github.com/Lash-L/pymyq/tree/useragent_fix

[jonheese]

@vincebel8 Yes, I used the zip file from that fork, but I assume it's the same code.

[eliasisrael]

The bug is on line 124 of request. py.

the 429 status returns a header named "retry-after". That field specifies the number of seconds the Client must wait before trying again. Instead, the code on line 124 tries to do exponential back-off, but it starts from a very small value.

If you look at the error header, you will see the server is asking for a wait time of 1750 Seconds or more.

See this link:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After

This explains why shutting down the module and waiting seems to fix the problem. And it explains why the problem is intermittent: it is happening on the Oauth auth cycle, which is somewhat infrequent.

The stuff about user agent strings is a red herring.

[eliasisrael]

@ehendrix23 please see above

[eliasisrael]

I will also note that the exponential backoff as implemented is broken.

The wait time is computed as the min() of 2 raised to the power of the attempt number , or 5.

So, as successive attempts unfold, the wait times will be:

2
4
5
5
5
5
...

And so on.

What was meant was probably max(2**attempt, 5). That might actually work, even though it's not correct behavior in the face of a 429 error.