Need a non-caching version of the client

[petewall]

I'm using this to build a deployment in Kubernetes, so the process will stay alive for a long time, unlike a CLI program. It'd be nice to make a version of the client that doesn't use the cache file.

[petewall]

If you're interested, I could try and whip up a PR for this. It'd keep the original behavior intact.

[rspier]

I'm not opposed...... but.....

Can you help me understand why the cache file is something you want to avoid on Kubernetes? The process might stay alive for a long time, or might be killed at any moment.

Ecobee refresh tokens only last for 30 days so if you aren't storing fresh refresh tokens at least that often, you'll be in a bad way. https://www.ecobee.com/home/developer/api/documentation/v1/auth/token-refresh.shtml#:~:text=on%20handling%20errors.-,Token%20Expiry,-The%20following%20table

Thinking about how I might implement this, the simplest thing would be to use a PVC to store the authcache file. Alternatively, we could store the refresh (and maybe access) token back in a Kubernetes Secret, or dynamically in something like Vault. For the latter, I'd want to make a "pluggable" authcache system so you can choose how it is stored.

What were you thinking?

[petewall]

Yeah, good points. One of the thing I'm trying to avoid in a Kubernetes deployment is secrets stored on the file system, or anywhere except for Kubernetes Secrets. You're totally right that pods will go down without warning, so it'd need a way to store the current refresh token (and maybe access token) or generate a new one on startup...

[petewall]

I mean, Ecobee isn't the first to use refresh tokens, this has to be a solved pattern.

In an ideal world, I can deploy my ecobee data exporter (which uses your library) as a Deployment, along with a Secret that contains the client id, and maybe some other secret that'll let the process request refresh and access tokens.

[petewall]

This library is great, BTW! Happy that it exists!

[petewall]

Maybe I'm not fully understanding Ecobee's authorization process fully. Does the 30 day expiration of the refresh token mean that every 30 days, I'll have to do the manual process of loading the website, installing my app, and pasting the authorization code?

[rspier]

Maybe I'm not fully understanding Ecobee's authorization process fully. Does the 30 day expiration of the refresh token mean that every 30 days, I'll have to do the manual process of loading the website, installing my app, and pasting the authorization code?

After 30 days you can't use the initial refresh token to get a new access token.

As long as your job is running, you're fine, because every time you get a new access token, you get a new 30 day refresh token too. But once your job restarts, you need a still valid refresh token or you have to start over from scratch.

[rspier]

There are two ways to get the initial access and refresh token:

• https://www.ecobee.com/home/developer/api/documentation/v1/auth/authz-code-authorization.shtml
• https://www.ecobee.com/home/developer/api/documentation/v1/auth/pin-api-authorization.shtml

both require some user involvement.

[rspier]

https://kubernetes.web.cern.ch/blog/2023/04/12/propagating-oauth2-tokens-made-easier/ looks like an interesting approach. It might need some tweaking. (This is basically outsourcing the refreshing to the operator, which stores it in a Secret for you.)

[petewall]

Great resources. I still want to think about this and the best way to deploy something with this library in K8s.
Honestly, this was a winter break hack project for me, but I do want to return to it...
Just letting you know I haven't dropped this.