Try token refresh on HTTP 403 response
RichieB2B opened this issue · comments
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.
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.
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.