Potential API change causing /connect/authorize to always 403 from this library

[naterator]

Describe The Problem:

Initializing a myQApi with a valid username/email and password (in my case via homebridge-myq) appears to always return a 403 upon the HTTPS call to this endpoint:

https://partner-identity.myq-cloud.com/connect/authorize?client_id=IOS_CGI_MYQ&code_challenge=XXXXXXXXXXXXX&code_challenge_method=S256&redirect_uri=com.myqops%3A%2F%2Fios&response_type=code&scope=MyQ_Residential+offline_access

Apologies in advance in the case that this is a myQ service issue. Signing into the myQ iOS app itself appears to work just fine for my garage and device, which makes me suspicious that their API is now blocklisting requests from some client types. To note, this is occurring at 2023-09-08 22:37:31 UTC.

To Reproduce:

1. Initialize a myQApi with a valid myQ username/email and password.

Logs:

Many continued instances of this error:

myQ API error: Forbidden API call. This error is typically due to an offline or unavailable myQ device

Screenshots:

[jweatherspoon]

+1

I am seeing the same Forbidden API call message when calling refreshDevices as of yesterday evening.

[black-ops-drivers]

For what its worth @hjdhjd, I noticed some changes to the API as it broke my myQ integration in a Control4 driver written in lua. I fixed it by adding seemingly newly required User-Agent headers everywhere. Worth a look here.

[black-ops-drivers]

Im guessing this no longer holds: https://github.com/hjdhjd/myq/blob/main/src/myq-api.ts#L124

[hjdhjd]

Thanks, will take a look…though I think this fact pattern is closer to just the occasional quirkiness of this API. That said, it seems that specifying a specific myQ region to the constructor (east or west) will work around the issue for now.

Given that the issue is mitigated by that, my suspicion is that this is more just a buck with the load balancer/redirector myQ is using on their end at the moment than a fundamental API change.

[black-ops-drivers]

Yeah it’s possible it’s just rejecting it at the load balancer.

[hjdhjd]

Im guessing this no longer holds: https://github.com/hjdhjd/myq/blob/main/src/myq-api.ts#L124

Perhaps…but a lot of history in working with this API has taught me that there’s nearly always a reason that’s far simpler than an API change. Occam’s razor etc.

Thanks for raising the point, but we’ll see what the next couple of days bring. Cheers.

[heisler3030]

There is quite a bit of chatter about this over in the home-assistant issues; they seem to have resolved it by adjusting the user-agent.

Personally I am encountering this issue a bit differently. My setup uses an AWS lambda which polls the API every 5 minutes. Historically I did see the occasional up/down as the API hiccuped but lately it is failing with 403's 100% of the time. However, if I trigger the lambda from my local dev environment, it works fine.

Best I can tell, the only difference is the source of the request, leading me to think that they have implemented some sort of IP blocking. I'm sure this is within the capabilities of Cloudflare, which they seem to be employing.

Taken together it does seem like they have taken some steps to more explicitly crack down on unsanctioned third-party usage. I may try to experiment with a fork that allows user-agent or client_id changes (I have no idea what the latter does, tbh) but I have low expectations for success there, given it is working as-is from my local address.

Curious to hear if there are others using AWS facing similar issues (or not).

[InnovoDeveloper]

I am experiencing this issue but in HA. I was able to patch HA using the fixes discussed for the user agent and it works from my local HA install. However, when I apply those very same changes to a server that I have running on AWS, I get 403 error. If I test it using my local dev server (a duplicated of the AWS instance), it works with no issues. So I do believe that they are implementing an AWS block. I have tried different AWS regions and rotated IP addresses, same result.

[hjdhjd]

You can see my comment on the HA thread you mentioned.

TL;DR: no, the user agent “fix” isn’t a fix in my experience. This is a load balancer problem on the Azure end of the myQ cloud. It’ll get resolved when they resolve their infrastructure challenges, if history is an indicator. The Azure cloud has had its share of challenges over the past few weeks across the board.

I’m open to other “changes” that might happen, but in truth - they just don’t happen all that often. I’ve been developing / maintaining this API for a very long time…Occam’s razor applies almost always. I don’t think the simplest explanation is a sudden blacklisting across the board…they have historically, and regularly, had cloud infrastructure configuration challenges. Given that the API that I, and others, have reverse engineered over the years polls the infrastructure rather than receiving published events as the myQ app does, we’re going to encounter a lot more issues when those challenges occur.

I largely consider this issue closed until there’s a significant enough body of evidence (as in weeks, not a couple of days) of being completely unable to login or access the API. That’s just not the case…I appreciate folks rely on, and enjoy using, the solutions we’ve all created over the years, but sometimes the actual solve is: just give them a minute to fix it…I’m sure some developer/engineer on the myQ end of things is having a tough couple of days too. 😄

[github-actions]

This issue is locked to prevent necroposting on closed issues. Please create a new issue for related support requests, bug reports, or feature suggestions.