-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API token tweaks #388
base: main
Are you sure you want to change the base?
API token tweaks #388
Conversation
We could end up with weird behaviour if the same access token digest is present twice in the database.
It is considered good practice to add a prefix to API keys so that they are easier to identify [[1], [2]], both for humans and machines. [1]: https://github.blog/2021-04-05-behind-githubs-new-authentication-token-formats/ [2]: https://tailscale.com/kb/1277/key-prefixes
Quality Gate passedKudos, no new issues were introduced! 0 New issues |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, think both of these changes make sense. I like the fact the test allows for the digest to be the same, I'd never have thought of that!
Hi @lfdebrux Can I double check why this is needed? Have we introduced some way for devs to insert their own generated token? I'm asking because originally the idea was that the model would control the value of the token digest being generated so in theory there should never have been duplicate token digests |
Yes, see #368 |
thanks @lfdebrux I've posted a message about allowing devs to use whatever token they like, |
What problem does this pull request solve?
While working on #368 I realised that we don't have anything preventing the same API token being used more than once. This seemed like a bug to me, so I've tried to fix it.
I've also thought it would make API keys easier to identify if they have a prefix, the same way GitHub or Trello does, so I added that as well.
These changes shouldn't stop any existing API tokens from working.
Things to consider when reviewing