copr-cli command to renew API token

[fedora-copr-github-bot]

Original issue: https://pagure.io/copr/copr/issue/2034
Opened: 2022-01-11 23:09:29
Opened by: brianjmurrell

For automated build systems, it's a pain for an admin to have to stop what he is doing and renew the COPR API token every 6 months. But I can appreciate you wanting to cycle them with some frequency and allow tokens that are not still in use to expire.

Given those requirements, it would be useful if there were a copr-cli command to renew a token given a valid token.

Automated build systems then could simply copr-cli renew the token every (i.e. 5 months) using the existing valid token.

---

praiskup commented at 2022-01-17 13:37:29:

Per discussion on the meeting today:

• using the kerberos AUTH, this would be pretty trivial (once krb is implemented)
• we could alternatively allow API tokens with longer validity (using a web form), as we manually did several times before

Also, as a security feature, we should display the token only once in web-UI, when created (this is a pretty common thing in other services).

[brianjmurrell]

using the kerberos AUTH, this would be pretty trivial (once krb is implemented)

Could you elaborate on this? AFAIU, kerberos tickets have a finite lifetime also. Typically one gets a ticket with a relatively short life-time (say, 24h) but with a renewal period that is longer (say, 30 days). But ultimately, once the renewal life-time is up, kerberos requires the user to enter their password again to start the process over again.

Unless you are referring to service tickets, but then I'm not sure why those would be any better than ...

we could alternatively allow API tokens with longer validity (using a web form), as we manually did several times before

Why not a possible infinite expiry like other services do with their access tokens. GitHub for example understand that these tokens can go into automated (i.e. CI) systems and having those systems break simply because a token has expired is just not nice at all.