Key Refresh / Regeneration Helpers

[techdragon]

Is your feature request related to a problem? Please describe.
A common workflow when using API keys is to "regenerate" a key in the case where there is some kind of 1-1 correspondence between a key and some other model instance, and the user wishes to "recover" the value.

Describe the solution you'd like
A built in mechanism for key 'refresh'/'regeneration'. Such as an Admin action, and a helper method similar to create_key

Describe alternatives you've considered
It would be possible to implement this all manually with create key and the existing documentation, but this seems to be the kind of reusable functionality that others would also want/benefit from.

Additional context
N.A.

[florimondmanca]

Hi!

So, a couple of questions to help framing this more…

• If I understand well, the goal is to create a new API key while retaining associations to any linked models, correct? For example, if I have an Organization model and an OrgAPIKey model, we'd like to push a button/have a method to say "regenerate this API key in place because"?

  (I'm not sure the "in place" part can technically be done today, because the primary key of API keys depends on the prefix and hash -- we need to change that as it's causing issues, see Simplified autoincremented integer ID migration #61.)

• Currently, I assume the alternative is to:

  1. Create a new API key with the same links as before.
  2. Delete the previous API key.

  Is this even possible, or do we typically come across issues with database constraints?

• If this had to be done manually, what would it look like in code?

• Can you share your particular setup/code that demonstrates what you're trying to achieve exactly?

Thanks!

[techdragon]

My Initial use case was actually laziness. I was testing things and kept losing track of API keys during manual testing, and the only "easy" way to get another one was to make one in the admin. Which lead to a lot of API keys and having to delete them whenever I made a new one. I figured I should offer more justification than "Please help me be lazy?" 😉 Which is why I mentioned associating keys to other models.

My usual experience with API keys in other systems tends to boil down to one of either 2 workflows. "Named Key" + "Refresh Key Button", this is basically the GitHub Personal Access Tokens workflow, the other is "Multiple Keys" + "Explicit Associations between keys and other things" + "New Key Button" + "Separate Expire Key Button", this is pretty much the AWS Access Key ID & Secret Access Key style of workflow. At the moment the library feels more like its built for the AWS style API Keys, vs the GitHub style Personal Access Tokens. I'm essentially looking for better built in support of the GitHub style workflow.

Having followed the chain of Issues & PRs around #61 I can see that perhaps the library isn't currently in a position to implement this cleanly. But it also looks like your intention is to get past the limitation and make it possible/easy to associate API Key model instances to other Django model instances via FKs just like any other django models. Once the PK and the hash/prefix aka "the API Key" are decoupled, then it should be possible to update them "in place". While it would be possible to build something right now that would work, judicious use of m2m through tables etc... After reading through the #61 chain, I'm not sure its worth trying to write any examples to solve this until after that is locked down.

Thoughts @florimondmanca ?

[florimondmanca]

Thanks, that's helpful info! Esp on the different workflow between GH-style and AWS-style keys.

Right now the hash/prefix being embedded in the PK prevent the API key from being replaced in-place (i.e. keeping the same DB row to represent a different API key). As you said, the API key identity (its PK) and value (the hash/prefix) are coupled right now.

Once we solve #61, we can get back here and address regeneration. I think there'll be some design around whether we'd like to enforce a separation between the two workflows (e.g. being able to mark an API key instance/model as "frozen", i.e. "can't be regenerated"?).

So yup, for now this is blocked on #61.

If you find any workaround in the meantime, such as a helper function to create a new API key and update any FKs, feel free to post it here. :-)

[techdragon]

This is still blocked, but now by #101 😄