xperimental / netatmo-exporter

Prometheus exporter for Netatmo sensor data.
MIT License
44 stars 18 forks source link

Try token refresh on HTTP 403 response #55

Open RichieB2B opened 11 months ago

RichieB2B commented 11 months ago

When I generated the tokens on https://dev.netatmo.com/ there was no expiration date displayed, so I guessed one to put in the token file. It turns out I set the expiry too long. After a few hours the token expired on the netatmo servers, but netatmo-explorer still thinks it is valid. It continues to try the old token even though the netatmo server responds with HTTP 403.

It makes sense to try a token refresh when the netatmo server starts responding with HTTP 403. After all that is how HTTP 403 should be interpreted in this case: access expired.

xperimental commented 11 months ago

Hi @RichieB2B , thanks for the input.

My workaround for the "the web interface does not provide any expiry" was to automatically add a very short expiry to the token, if none is specified. This triggers the refresh process as early as possible and produces a token with known lifetime. In my opinion this is a better approach than retrying the request on error, but it might not be immediately obvious. It is documented though.

I'm also not completely sure that the refresh-on-error approach works. If I remember correctly, then access-tokens should only be refreshable during their lifetime and not afterwards to avoid security issues with "reviving dead tokens". I do not know how NetAtmo has implemented their service though.

RichieB2B commented 11 months ago

Yes, I found the documentation after I ran into this issue. I didn't think to leave out the expiry field entirely. Your approach seems solid. If the refresh token has the same expiry as the access token, my suggestion makes no sense.

xperimental commented 2 weeks ago

@RichieB2B I know it's been a while. Are you fine with closing this issue?