-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update login to work around server-side 403 error #22
Conversation
Thanks for taking care of the PR! |
pymyq/api.py
Outdated
# Perform login to MyQ | ||
_LOGGER.debug("Performing login to MyQ") | ||
resp, _ = await self.request( | ||
method="post", | ||
returns="response", | ||
url=resp.url, | ||
url=OAUTH_LOGIN_URI, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe resp.url was typical /LoginWithemail
Any idea what was different between it and this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was returning /Login
, but the submit action on the web form is /LoginWithEmail
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually didn't dump that to sanity check it. The comments in the other thread made it sound like this had changed and hardcoding was necessary, but maybe I misunderstood. I'll test the original URL once my rate limit expires in about 20 minutes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was returning
/Login
, but the submit action on the web form is/LoginWithEmail
Interesting - I could have sworn I saw LoginWithEmail in the past - but perhaps that change was part of their most recent changes. Thanks
@justinlindh when you have a chance to test and confirm everything - undraft and I will merge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'm assuming they updated the header on their side for whatever reason to be different from the actual submit path in the form. Ideally we'd extract the submit path from the login form dynamically rather than relying on the response headers or a const. When I called it out in the other thread it was just to point out the discrepancy, so this is a bit of a quick-and-dirty fix, which is probably fine for now, but may wish to be more robust when someone has time to do so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get redirected to /LoginWithEmail
from the initial /connect/authorize call, not /Login
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/shrug Not sure, just what I observed when testing. Who knows with MyQ, they seem to be in constant flux. Either way, it makes more sense to get the form post URL from the form itself than from response headers imo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it's returning this for resp.url
https://partner-identity.myq-cloud.com/Account/LoginWithEmail?returnUrl=/connect/authorize/callback?client_id%3DANDROID_CGI_MYQ%26code_challenge%3<REDACTED>%26code_challenge_method%3DS256%26redirect_uri%3Dcom.myqops%253A%252F%252Fandroid%26response_type%3Dcode%26scope%3DMyQ_Residential%2520offline_access
So it actually is the LoginWithEmail
path.
Tested reverting back to using that value and the plugin still succeeds. Will push an update to remove that part now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, it looks like this was a difference in packages, not responses. The (Go) package I was debugging from was referencing the incorrect URL. Apologies for the confusion.
Tested locally and working as expected. Marked ready for review, @Lash-L Thanks, all. My garage door works again! Until the next round, Chamberlain... |
+1 c704b34 |
If either of you have a chance, take a look at the changes hjdhjd made so we can attempt to do the same and hopefully avoid another lockout I'm still rather busy right now, so I probably wont have a chance to do so until sometime next week |
I'm also going to be busy with work all day, so I won't be able to look until tonight at the earliest. Others are certainly welcome to jump in on this one. @Lash-L - have you confirmed that hjdhjd's code is still working? |
@justinlindh I have not - no |
I peeked into the issue tracker on their repo, and it looks like they're likely dealing with the same issue. Someone on the other thread mentioned that they think MyQ is starting to implement cloudflare protections (maybe fingerprinting), which I think is likely. I've hacked around some of those in the past, using https://github.com/lwthiker/curl-impersonate (it's basically a custom build of curl/libcurl that impersonates Chrome or Firefox decently well). There may be a workaround there (replacing the http requests in this integration with calls to modified libcurl), but I suspect it could require an implementation in an add-on versus just modifying the library here. Anyway, if someone wants to test that theory, they should be able to export their current postman calls to cURL and give the compiled binaries in the repo above a shot. Ultimately, hacking around cloudflare is a heavier lift than I'm personally willing to volunteer for at the moment. I'm personally just going to install one of the hardware workarounds and ditch MyQ altogether, as they're very clearly trying to block third party access, and even if this next stumbling block is circumvented, I'm positive that they'll keep working to actively block out third party users. Thanks again for working on this library! I enjoyed it quite a bit while it was working. |
I'm still locked out of the API so haven't been able to test, but planning on checking if the homebridge plugin is still working. Assuming it works, can port the same changes over but I definitely was not expecting them to put up this much of a fight. I've also ordered a ratgdo to avoid this headache, but will do my best to help fix this library if i can. |
Strangely, I just re-enabled the integration and it seems to be working again. I wonder if they walked back the most recent change on their end. I'll monitor it and see whether it remains stable, but that's at least good news for now. FYI @dailow (since I know you were planning on messing with this) |
I'd re-enabled it last night and it worked just fine until it needed to refresh its OAuth token, and that's when it started generating 429s; so keep an eye out for that. |
It appears homebridge plugin is also not working, so looks like even the latest changes there wouldn't help. Appears some active discussion on the project on the homebridge discord, so I'll see if any progress can be made there. I imagine they must be doing something on the server side or through Cloudflare as I can't imagine they could have made major changes to all the clients so quickly. |
I just tested my Homebridge plugin for my door and it was able top open and close it. HA integration is broken for the last couple days. Am I missing something? |
This issue (and many other closed ones) has more information: hjdhjd/homebridge-myq#1133 Your homebridge plug-in will likely stop working if/when the token expires and the plugin tries to refresh or reauthenticate. |
Got it thanks, I don't actively use HomeBridge just have it set up for test scenarios, and installed the MyQ plugin when the original HA integration stopped working. |
This PR addresses the recent change to Chamberlain's account login flow, which now seems to require
brand
andUnifiedFlowRequested
parameters.Changes were also made to mimic the Android application for CLIENT_ID and REDIRECT_URI. These changes appear necessary, due to however they're handling the flow on their servers.
Proper credit for this fix goes to drysart, dailow, and brchri for doing the hard part of debugging and dumping the actual application login/oauth flow to find this solution.
Addresses home-assistant/core#101763 and #19