uvjim
FR: Node Re-Authentication
I've noticed that if you change the password via the Router/Node login page, the integration keeps attempting to login with the old password. Which results in a Access lockout for local access, due to too many failed attempts.
I'm not sure if you're able to implement a way to only re-attempt once, and if that fails show a repair issue in HA to re-authenticate? This way, it will prevent the router login page from being access locked.
If not, maybe add an option to be able to change the node password for existing devices? Currently, the only way to update this is to delete, and re-add the node(s) again, which is quite cumbersome.
Thanks
Assuming that you're using the latest version there should be a reauthentication flow that is followed. It could be that this doesn't follow in all cases. In which case I can address that. Either way, rather than re-adding the nodes (not sure what you mean, because you only need to add the primary node when setting up the integration), you could just reload the integration and it should follow the reauthentication flow.
The simplest way, if changing the local password on the Linksys router, is...
- Disable the integration in HASS.
- Make the change on the router.
- Enable the integration in HASS which should then follow the reauthentication flow allowing you to put the new password in.
Assuming that you're using the latest version there should be a reauthentication flow that is followed. It could be that this doesn't follow in all cases. In which case I can address that. Either way, rather than re-adding the nodes (not sure what you mean, because you only need to add the primary node when setting up the integration), you could just reload the integration and it should follow the reauthentication flow.
Before I could reload the integration, I was already greeted with access lockout straight after I changed to router password. I suspect the integration (as nothing else is using my login) was trying to re-attempt multiple to times in quick succession's, so I had no chance of seeing the re-authentication flow. Also, I was referring to Primary node only, as I only have one.
The simplest way, if changing the local password on the Linksys router, is...
- Disable the integration in HASS.
- Make the change on the router.
- Enable the integration in HASS which should then follow the reauthentication flow allowing you to put the new password in.
Though, it's rare that you change your master password often, I don't feel this is a intuitive way to handle this, in all honesty. I wasn't aware that I needed disable the integration first (which likely be the case with others). I think one of the two options mentioned above would be a better way to handle this.
Yes, it's rare, and the integration will only be polling regularly if you have device_tracker functionality enabled, otherwise it'll be going based on the poll time. Default is every minute, by the looks of it (been ages since I looked at this code for much).
I'm not really sure how the 2 options you outlined help much either really...
- It's quite possible that only a single retry isn't enough, what happens if there's a glitch on the router that ignores a couple of requests or rejects a couple for auth issues (had that recently on a different system when there wasn't anything wrong with the credentials I was using. An arbitrary number of retries could still be enough to lock that account out on the router, and I can't remember seeing anything in the API that tells me how many attempts are allowed.
- Entering the password again, manually doesn't solve the issue, it merely avoids having to delete and re-add the integration, which in my experience is probably just as quick as going through options to change the password in the first place. The only time this causes an issue is if you've customised the entity/device names.
Don't get me wrong, I'm not adverse to doing something about it, but it's having a solution that is meaningful and worth the effort that it'll take to implement it.
RE: being intuitive, they may not be, but in addition it's not often that I change a password to a service and don't expect it to have a knock-on effect somewhere, so if I know that the I use those credentials elsewhere, I'd probably check those places either before making the change, or expect to have to so something after the change.
Maybe a stop gap solution is as simple as checking the code to see if the reauthentication flow is followed during normal polling rather than at initialisation. If it should be, but isn't then that's a bug. If it isn't even there, then it's a new feature that needs to go in.
I hear what you're saying about the polling. My main issue is that I was instantly locked out after changing the router password, which was caused by the integration attempting to re-authenticate multiple times in frequent intervals. I didn't have any time to react or use a workaround before the lockout happened. If there was some sort of timeout or reduced auth re-attempts, maybe I could've rectified it in time.
I was also suggesting that raising a user-facing notification (like an HA Repair prompt) instead of it happening silently, would help alert users before the lockout occurs.
I don't fully understand the technical side of it, but if there's something you could do to prevent the silent lockout, it would be very much appreciated. Either way, I understand if it's not feasible.
Right, I've had a quick look at the code, seeing as it's Friday. 🤭
It looks like authentication is only checked for validity when the integration starts up.
I'll have to look at the pyvelop module to see if that raises a distinct authentication exception during normal usage. If it does I can look to see if the various routes of gathering information adhere to that and trigger the reauth flow. If not, I'll have to change the modules accordingly first.