Constant authentication requests since last update

[garybrowngeo]

Since the update I am getting constant emails notify me of one time code and new login almost every minute! Has something changed in the last updates? Is there a way to stop this?

[Phoenix-DH]

Same here, but I have nothing in the logs.

My config:
version: 1
aarlo:
mqtt_host: mqtt-cluster-z1.arloxcld.com
user_agent: linix

[twrecked]

Arlo changed the backend around. Can you upload some logs?

…

On Thu, Feb 13, 2025, 04:48 Gary Brown ***@***.***> wrote: Since the update I am getting constant emails notify me of one time code and new login almost every minute! Has something changed in the last updates? Is there a way to stop this? — Reply to this email directly, view it on GitHub <#1046>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHJU6RYXCZKXZXTTNOA5DT2PRS7VAVCNFSM6AAAAABXBXEB2CVHI2DSMVQWIX3LMV43ASLTON2WKOZSHA2TANJRHE4TIMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[garybrowngeo]

home-assistant_2025-02-13T09-59-20.066Z.log

This is my latest log file - I have rolled back to 0.8.1.11 at the end of the logs to try and remediate just in case this looks weird!

[Phoenix-DH]

I am not at home was only wondering why there are so many mails.

[garybrowngeo]

The rollback seems to have stopped the mails for now so could be the user agent change causing arlo to think theres a new device all the time?

[garybrowngeo]

The issue seems to have started about 06:52 this morning.

[twrecked]

It started for me at 4 in the morning. I have verbose debugging on and I'm seeing this error:

{'data': {'error': '2015',
          'message': 'Your session has expired. Please log in.',
          'reason': 'Invalid Token'},
 'success': False}

It looks like they've added a timeout to the event stream. A work around might be to add reconnect_every: 25 to your aarlo.yaml file.

I'll look into this some more.

[Phoenix-DH]

Will try, thanks.

[twrecked]

They've changed the general timeouts to 30 minutes and this includes the access token. It used to be 2 weeks. This is the
same on the web browser.

I need to modify the login code to "trust" the Arlo session and stop the emails happening - this should be possible. For now I think you are going to get those messages every half an hour.

I'll take a look at it today.

[Phoenix-DH]

I think the value 25 had no effect.

Thanks for your work.

[twrecked]

I realised you're still going to get the emails but it should have stopped the errors.

[yongfg]

Just realized they change the access token expiration to 2 hours. This is what I got when inspecting the login from an incognito window. So Im sure this is not related to how we mock the payload

{
    "meta": {
        "code": 200
    },
    "data": {
        "expiresIn": 1739498798,
        "mfa": true,
        "_type": "AccessTokenV2",
        "authenticated": 1739491598,
        "issued": 1739491598,
        "userId": "...",
        "token": "...",
        "authCompleted": true,
        "MFA_State": "ENABLED",
        "browserAuthCode": "..."
    }
}

First of all this will break the intention of the check session we do now:
get_new_session = days_until(self._expires_in) < 2

Secondly, not sure if this is related to many issues we've been experiencing recently.

[twrecked]

@yongfg that is exactly the problem

The way this used to work was

On the first login:

• we login
• we do our 2fa
• we get an authentication token which had a timeout of 14 days
• we validate the token

For logins with in the next 12 days:

• we logged
• we revalidate the token

For logins within the 12 days we didn't need to ask for a 2fa code.

What changed

But with the new back end changes arlo has reduced the token timeout to 2 hours (it was actually 30 minutes earlier today). So once that token expires we need to get use 2fa to get another token.

What I'm looking at

I'm testing a pyaarlo branch that makes the component mock the web browser even more closely. With the new changes:

On the first login

• we login
• we do our 2fa
• we get an authentication token which has a timeout of 2 hours
• we validate the token
• we tell arlo to trust this browser

On subsequent logins:

• we login
• if we are on a trusted browser we get a new token without 2fa
  • we validate the token
• if the trust has expired we start 2fa again
  • we do our 2fa
  • we get an authentication token which had a timeout of 2 hours
  • we validate the token
  • we tell arlo to trust this browser

The branch is working pretty well but I'll run some more test tonight. Once this workaround is in place I'm going to revisit and refactor this code, it started off simple and has morphed into quite the lump of spaghetti code over time.

[yongfg]

Haha totally, I was also messing the code in the similar direction but got no luck. I tried to inspect if they have some token exchange logic or if this field browserAuthCode could be helpful. But I'm so glad you figured out we can utilize the trust of the browser, like the page user has to click on trust right. This also means we need to maintain the same browser user agent across different sessions.

Looking forward to the fix and I'm willing to help test and clean up if needed! Thank you

[yongfg]

Im seeing a new update for the pyaarlo repo. @twrecked Thank you for the push! I'm wondering if there's an efficient way to test this. I kinda don't want to always wait for 2 hours before figuring out if the changes are working.

Also for the new approach, does it matter if we have to be consistent on the user agent?

[twrecked]

@yongfg you can set reconnect_every=15 to force a disconnect every 15 minutes and it will try and login again

The disconnect mechanism is different but the overall effect is the same.

[twrecked]

This should be fixed in v0.8.1.15 if people want to give it a try.

I've had to modify the authentication code and I've tested as thoroughly as I can on my setups. But experience has shown Arlo to be an odd beast so if you run into issues please post some debug logs here.

You can return to v0.8.1.41.1 and it will use the old authentication mechanism.

[yongfg]

@twrecked From my understanding of the code, it looks like we always try to do auth with username and password. And for the happy path, we don't have to do 2FA. My question is, does it mean that at least the username and password should always be available? Like we can't silently refresh the access token without the username and password?

[twrecked]

Good questions. My goal here was to get it working but it's strained the current code to breaking point.

So I don't know the answer just yet but I suspect as long as the browser token is valid we might be able to skip to login. But I'm just guessing.

Once I've tidied the state machine I should have a better understanding and I'll give it a try.

[Phoenix-DH]

Will give it a try today with the latest release.
One question:
Keep reconnect_every: 25 in the yaml or remove?

But I only get 14.1:

[hceuterpe]

I'm still getting regular app approval prompts in less than an hour apart with .15...

[twrecked]

@Phoenix-DH did you find 15? You might need to get HACS to update its information

@hceuterpe Can you attach some logs.

[Phoenix-DH]

Yes, just did the update and removed the lines in the config.
Will give feedback.

Thanks.

[twrecked]

@Phoenix-DH excellent, let me know how it goes

[Phoenix-DH]

Again up and running 👌🏻
Lets see.

Restart 11:16am.

[twrecked]

@hceuterpe At the computer now...

• can you double check the installed version? looking at the screenshot above it might be possible to get the wrong one
• if you are good, can you turn on verbose debug and attach some logs, it's the only way I'll be able to see what is going on

edit: you are using the push mechanism? I just realised that I'm not setting the trusted browser on that. The code has 2 paths that do essentially the same thing. I'll fix it. For now you if you have set reconnect_every you can remove that.

[Phoenix-DH]

Until now …. No mail … still working.

[twrecked]

@hceuterpe can you try the 16 release. It might/should fix it.