Authentication failure - Githubissues

Rom1-B commented 6 months ago

Describe the issue

I can't authenticate on Landroid_cloud. According to the logs my mail/password would be wrong, but they work on the Landroid app. So I don't think that's it.

I've tried several times to disconnect my mower from the app and reconnect it, as described in the README, but I'm still stuck.

What version of Home Assistant Core has the issue?

core-2024.3.3

What was the last working version of Home Assistant Core?

core-2024.3.3

What version of the Landroid Cloud integration do you have installed

v4.0.3

What type of installation are you running?

Home Assistant OS

Which make and model is the mower used for this integration?

Landroid WR153E - Firmware 3.32b1 - WORX

Diagnostics information (NOT log entries!)

None

Relevant log entries

2024-03-24 17:09:52.410 DEBUG (MainThread) [custom_components.landroid_cloud.config_flow] (Config) data: {'email': '***@***', 'password': '*****', 'type': 'Worx'}
2024-03-24 17:09:52.411 DEBUG (MainThread) [pyworxcloud] Initializing connector...
2024-03-24 17:09:52.411 DEBUG (MainThread) [pyworxcloud] Try getting correct CloudType from WORX
2024-03-24 17:09:52.412 DEBUG (MainThread) [pyworxcloud] Found cloud type <class 'pyworxcloud.clouds.CloudType.WORX'>
2024-03-24 17:09:52.412 DEBUG (MainThread) [pyworxcloud] Initializing the API connector ...
2024-03-24 17:09:52.412 DEBUG (MainThread) [pyworxcloud] Getting logger ...
2024-03-24 17:09:52.413 DEBUG (MainThread) [pyworxcloud] Initializing EventHandler ...
2024-03-24 17:09:52.414 DEBUG (SyncWorker_13) [pyworxcloud] Authenticating ***@***
2024-03-24 17:09:52.563 DEBUG (SyncWorker_13) [pyworxcloud] Authentication for ***@*** failed!
2024-03-24 17:09:53.716 ERROR (MainThread) [frontend.js.latest.202403070] Uncaught error from Firefox 124.0 on Windows 10
Error: Permission denied to access property "localName"
element (src/blocking-elements.ts:372:56)
sibling (src/blocking-elements.ts:355:34)

Additional information

No response

danielk117 commented 5 months ago

I will wait until the 24 hours are over. If I'm still receiving the 429 error, I will try to get around the device fingerprinting...

If I'm not successful, I hope migrating my data to a new HA container instance might be a solutiuon.

danielk117 commented 5 months ago

I'm still blocked. Recreating container didn't solved it.

I did some research about fingerprinting technologies, but I have no idea why it is working in a fresh container (which seems to have the same fingerprints as the old container). ☹️

danielk117 commented 5 months ago

I've found a workaround (at least for me with my container setup). Just migrating my data to a new HA container is not enough, as my main HA container is running as network_mode=host (needed for zeroconf broadcasting stuff). So the HA instance and host system has the same IP/MAC address and my whole container host (or its ethernet IP/MAC address, fingerprint, whatever...) is blocked at the Worx services. Any new container with network_mode=host is blocked too.

When testing with a second fresh HA instance, I was using a docker network bridge instead of the host network. So the container has a different IP/MAC address than my host. This seems to be the reason, why it was working for me with "a fresh instance".

So as a workaround, I'm running a https proxy (e.g. squid) as container with a network bridge. In my HA instance I added the proxy as a environment variable (HTTPS_PROXY=http://localhost:3128). Thats it. All outgoinbg https traffic from the container is now proxied trough the proxy container.

I don't know how you other guys in this issue are runnning HA. But using a proxy (container, other host or something else) might also work for you. I hope that waiting a few more days, weeks (or perhaps months 🙄) will be enought to get unblocked and I could remove the proxy stuff...

MTrab commented 5 months ago

I have been talking to Positec about this issue, and the do indeed block the IP address for a duration between 5 minutes and 24 hours. But the block is for IP address AND user credentials, so that's not the actual issue here I think, as a fresh HA instance on the same IP and credentials indeed works.

I have NO idea what to do next, for solving this issue. It seems to be related to some local thing in the Home Assistant instance, but what it is I have no idea to

MTrab commented 5 months ago

Just got an idea - could one of you try changing the pyworxcloud version in the manifest.json to read pyworxcloud==4.1.14b1 and see if that changes anything?

danielk117 commented 5 months ago

But the block is for IP address AND user credentials, so that's not the actual issue here I think, as a fresh HA instance on the same IP and credentials indeed works.

Yes, this isn't the problem. I'm blocked without sending any request data. I think the block is done on a TCP/IP stack fingerprint. So the outgoing (virtual or not) ethernet interface is blocked.

$ curl https://id.worx.com
429 TOO MANY REQUESTS
$ curl -X POST https://id.worx.com
429 TOO MANY REQUESTS

Or with reponse headers:

$ curl -X POST -D - https://id.worx.com
HTTP/2 429
date: Fri, 19 Apr 2024 11:28:23 GMT
content-type: text/plain
content-length: 21
x-ratelimit-throttle: true
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 876c8d02ad496967-FRA
alt-svc: h3=":443"; ma=86400

429 TOO MANY REQUESTS

It seems to be related to some local thing in the Home Assistant instance, but what it is I have no idea to

As written above, I think the block is based on the TCP/IP stack. So this issue is not HA related. Wo can do nothing.

I have NO idea what to do next, for solving this issue.

As you have contact to Positec: They need to check their rate limit throttling settings at cloudflare. There is more than IP address AND user credentials... I'm totally fine with blocking, when there are too much requests (for whatever reason). But there must be a normal wait time. And a Retry-After response header would be very helpful...

danielk117 commented 5 months ago

Just a short update: my proxy workaround is running over a week now. Everything is fine.

My host machine is still blocked. Same details as in my last comment. I don't why I get blocked so long. There can't be any request from my host for a week now. Really strange...

icesunny86 commented 5 months ago

Is the problem still being worked on, or did I somehow overlook the solution?

MTrab commented 5 months ago

"Worked on" as in I have absolutely no clue why this is happening, cannot reproduce and Positec cannot see why the connection isn't sucessful either. Your guess might be as good as mine

Rom1-B commented 5 months ago

Just got an idea - could one of you try changing the pyworxcloud version in the manifest.json to read pyworxcloud==4.1.14b1 and see if that changes anything?

Yes, it works for me, thanks 🥳 🎉

polomueller commented 5 months ago

Just got an idea - could one of you try changing the pyworxcloud version in the manifest.json to read pyworxcloud==4.1.14b1 and see if that changes anything?

Yes, it works for me, thanks 🥳 🎉

Unfortunately, for me it doesn't work. Went back to 5.0.1 and tried pyworxcloud==4.1.14b1, deleted and re-paired the mower -without any success. Still get "Too many requests to the API - Try again in 24 hours". I'll wait another 24 (or better some hours more) and will try it again.

polomueller commented 5 months ago

Problem solved. After update to HA 2024.5.1 login to landroid is possible again. Everything works fine.

danielk117 commented 4 months ago

Still blocked... I need to stay on my proxy workaround. 😞

ut0py4 commented 3 months ago

Hi, i've got the same problem since HA update 2024.6.0.

Initially the logs indicated IP banned : Too many requests for xxx@xxx.xx at Landroid Cloud. IP address temporary banned. I deactivated the entity then waited a few days, but same problem. Yesterday, I uninstall then reinstall landroid_cloud and now I get the following error message when trying to integrate my Worx robot: Too many requests to the API - Try again in 24 hours

Connection via the official application works correctly as well as connection to the id.worx.com site with a browser.

On the other hand, here is a screenshot of the command mentioned above, and I don't understand why I don't get a 429 response using curl:

If any of you have an idea that would be great ;)

Thanks

MTrab commented 3 months ago

It is an issue between Home Assistant and Landroid Cloud, as if you install a new Home Assistant, then the issue will be gone. Unfortunately I have absolutely no idea why this is happening :(

MTrab commented 3 months ago

I am considering rewriting it all from scratch and see if that will fix this, but that will be a huge task and I won't have time for that within the next few months

ut0py4 commented 3 months ago

Thanks for the response, i'll wait and use the official worx app instead ;)

polomueller commented 3 months ago

I have noticed a strange parallel. In the last few days, I encountered the familiar login problem again after the integration had been running smoothly for several weeks. Then suddenly, the problem reappeared. Interestingly, at the same time, the Tuya app also had a login issue. This was also the case with the last Landroid problems. A few weeks ago, the Tuya app was already ruled out as the cause. But maybe both integrations access similar structures in HA that lead to problems after updates. Perhaps this will help a little bit with troubleshooting.

Both integrations, landroidcloud and tuya, work fine at the moment. There were problems for about 3-4 days.

danielk117 commented 2 months ago

For me, the problem still exists. I'm blocked since 4 months and I don't know why. 😞 When this happend, I had one HA in my network (with two landroids for around 3 or 4 days) talking to the Worx API.

My HA is using a proxy all the time now, to get around this. (Just tested without proxy today, but still blocked.) If anyone is interested in my "proxy workaround with docker", I could provide some details.

@MTrab

I am considering rewriting it all from scratch and see if that will fix this, but that will be a huge task and I won't have time for that within the next few months

Are you sure, that would fix it? As the serverside API keeps the same, I think you could trapped into this, anytime again.

if you install a new Home Assistant, then the issue will be gone.

At least for me, this didn't work. As the hardware is the same...

You mentioned a contact to Positec/Worx. I think it would be helpful to know what limiting rules they use. (You already noticed some rules, but I think there is more than this.) Maybe you can integrate that rules into your project to avoid reaching the limitations. 😄

MTrab commented 2 months ago

I can't get a clear answer as to what the limiting factors is and why (at least for most people) it helps creating a new Home Assistant.

As for rewriting, there's more than this issue for that - it's a mess as I really haven't had the time to make the recent API changes the right way. Alot of code isn't even used anymore. Perhaps there is something interfering and creating this issue. Only problem is that I don't know when I have the time to do the rewrite - might not even be this year.

polomueller commented 2 months ago

In the meantime, I am completely confused. A few weeks ago, communication between HA and the mower resumed, but then it suddenly stopped again. Last week, everything suddenly worked as desired. The special thing: I was on vacation and did not make any changes to HA for several days. I only occasionally checked the status of the mower with the landroid app. I have no remote-acces to HA. After 4-5 days, the connection was lost again. Also without any changes.

Anyway, take your time… it’s just an integration for a lawn mower robot. There are a thousand more important things.

grenau commented 1 month ago

Hello, I have the same problem on my side and I just did a test that could give an idea of the source of the problem.

My HA is installed on a raspberry pi and connected to the network via wifi. In this configuration the curl command curl -Ivs https://id.worx.com always returns HTTP 429 and it is impossible for me to use the integration or even reinstall it.

By connecting the raspberry pi via wire (without any reboot or other change), the same command always returns HTTP 302 and the integration can be installed and works perfectly.

I am attaching the result of the command placed on both types of connection. Hoping that this will help move the subject forward.

wire.txt wifi.txt

MTrab / landroid_cloud

Authentication failure #538

Describe the issue

What version of Home Assistant Core has the issue?

What was the last working version of Home Assistant Core?

What version of the Landroid Cloud integration do you have installed

What type of installation are you running?

Which make and model is the mower used for this integration?

Diagnostics information (NOT log entries!)

Relevant log entries

Additional information