tsibley
commented
8 months ago So, I'm happy to extend the validity from 30 → 90 days. It'd be frobbing one number and deploying the change. I'll do that.
That said, I do wonder if expired logins will still be an issue, just less frequently so.
The login session validity period is mostly expected to affect interactive usage, not automated usage. For automations, instead of setting up a cronjob to periodically login (as you've done), the expectation is that the automation would always login before running other commands that need authn (like nextstrain remote). For example, instead of the automation expecting that
nextstrain remote upload …will just work due to an existing/background login session, the automation would instead run
nextstrain login --no-prompt && nextstrain remote upload …or the equivalent. This also self-documents in the automation itself that login is required (and thus that NEXTSTRAIN_USERNAME and NEXTSTRAIN_PASSWORD, etc are required).
Is there a reason that approach doesn't work for your case?
Context
I run some nextstrain builds for the neherlab group on a cluster in a cronjob and they work reliably. The one thing that makes them fail is expiry of
nextstrain loginrefresh tokens every 30 days. If I don't remember to runnextstrain loginwithin 30 days, deploys stop.This happens a lot unfortunately (yes I could set a reminder to login). I could make a cronjob run login with credentials every 30 days but for no reason I haven't set that up yet (I should).
We've discussed this in Slack a year ago on blab slack.
Description
It'd reduce failures by a factor of 3 for me (and everyone else) to extend the validity of refresh tokens to 90 days as was suggested by @tsibley here: blab slack