Cache Auth Token about wienernetzesmartmeter

[DarwinsBuddy]

I am not aware of any secure caching functionality right now in HomeAssistant. Although I guess the Wiener Netze API offers to renew a particular token by using the refresh token along side the access token, we cannot really persist them in HA I fear.

[reox]

Okay, but also username and password is stored? Can we not just use the same approach?

[DarwinsBuddy]

oh you're right. i forgot. yes we could. only thing left to check is, how we could renew a token. for that we would have to potentially wait for the session to renew itself in the browser and check the calls made in die tools.

…

On Wed, Mar 29, 2023, 14:41 reox ***@***.***> wrote: Okay, but also username and password is stored? Can we not just use the same approach? — Reply to this email directly, view it on GitHub <#83 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADX2VGPVEJMFT3SVSTRHNTW6QUYXANCNFSM6AAAAAAWIBGRCQ> . You are receiving this because you commented.Message ID: ***@***.***>

[reox]

Maybe it is a good idea to switch to a proper OpenID-Connect library, which can handle all these things.

I also checked the token response, they are valid for 300 seconds, and the refresh token for 1800s (30min).
Thus, with the change to request only every 60minutes, we would have to login any ways or have another job running in the background that does the refreshing.

I guess the website sets a cookie with a longer lifespan?

[DarwinsBuddy]

regarding OpenID: that would be for sure the more stable solution, though we are assuming that log.wien correctly implemented it according to the standard.
We may have to reverse engineer that part, but imho it's worth a try.

regarding the token: Home assistant does not provide afaik the possibility to launch separate scheduled tasks then the update lifecycle. What we could do is reduce the update cycle to happen < 30min and first use refresh token and if that fails as a fallback the credentials login and update the sensors merely every 2nd-3rd time.
If the refresh token endpoint is computationally more efficient (as it should not require a persistence lookup) we could save them some load and give back some performance.

What do you think @reox?

[reox]

regarding OpenID: that would be for sure the more stable solution, though we are assuming that log.wien correctly implemented it according to the standard.

The question is also if we are acting according to any standard :D

What we could do is reduce the update cycle to happen < 30min and first use refresh token and if that fails as a fallback the credentials login and update the sensors merely every 2nd-3rd time.

Or even reduce it to 5min and just update the API every half an hour. I implemented something similar with the statistics, to only query after 24h after the last imported stat, eve if the update function is called more often.

[DarwinsBuddy]

regarding OpenID: that would be for sure the more stable solution, though we are assuming that log.wien correctly implemented it according to the standard.

The question is also if we are acting according to any standard :D

For sure not. But as of my experience openId is often not implemented according to the standard. Just to keep that in mind, when integrating into an external system.

What we could do is reduce the update cycle to happen < 30min and first use refresh token and if that fails as a fallback the credentials login and update the sensors merely every 2nd-3rd time.

Or even reduce it to 5min and just update the API every half an hour. I implemented something similar with the statistics, to only query after 24h after the last imported stat, eve if the update function is called more often.
calling every 5 minutes is a bit too much. Most frequently 15 minutes is I guess already enough.
Regarding your grace timeout logic: I agree, we could probably think of update if next day after updatets at 00:00 < now

[reox]

I had a look on what is taking so long during login. It is actually the fetching of the API keys from the javascript files.
The file that has to be downloaded is 1.8MB (okay, it is gziped to 400kB..)
Maybe a good addition would be to cache these keys. For starters, one could take the proposed cache value from the http response.

[DarwinsBuddy]

there you have a point.
You've got a good idea there:

We could download and cache the keys (by downloading the html-file -> js-files -> api keys) if

• the cached key is None or
• the login with the cached key fails due to a wrong key, as a fallback

and use the cached one as long as it doesn't fail to login due to invalid keys
What do you think @reox ?

[reox]

I thought about that too. Probably would have to check in the _call_api function then if the call fails and if so, request new keys.