-
Sean Hammond authored
Add a /profile/developer/ page where users can generate and re-generate their API token. This token can be used as a Bearer token in the Authorization header in API requests instead of using one of the more complex and short-lived JWT tokens that the client uses to authenticate API requests. The tokens are just randomly generated opaque strings, each one associated with one user account. There's 0 or 1 token per user, and the user can regenerate their token at any time. The tokens are stored in a `token` table in the db that just maps token values to userids. Notes: - Our authentication policy now calls the new API token validator first for API requests. If this validator does not accept the token, then it passes it to the legacy JWT validator (which is still used by our client). The idea is that if we add more types of API token in the future, the authentication policy will have a list of different validator functions for different token types, and will try each validator in turn until either one of them accepts the token or it runs out of validators. The use of a type prefix string at the beginning of tokens means that validators can usually reject tokens without a db lookup, so we won't end up with one db lookup per validator. - The new tokens always start with u"6879-". If a token sent by a user doesn't start with this prefix then the token validator can reject it out of hand, without doing a database lookup. An opaque number is used for this prefix because we want users to treat API tokens as opaque, rather than using a human-readable prefix that makes it obvious what type of token you're looking at. (But the type of the token is not "secret" in any real sense.) In the future it's intended that we'll have different types of tokens identified by different prefixes, and different types of token might (for example) give access to different capabilities. - The legacy JWT tokens (still used by our own client) do not have any such prefix. If all other token validators (currently just the one new API tokens validator) reject a token, then the auth policy will fall back to the legacy JWT token validator. I think it might be possible that a JWT by random chance could begin with u"6879-". If that happens then the new API tokens validator would not reject the token based on its prefix and would do a db lookup, but the lookup would return nothing and the validator would then reject the token, and the auth policy would then move on to the legacy JWT validator which would accept the token. So it would be okay. - There's no foreign key constraint from the token table's userid column to the user table, because the user table belongs to the app whereas the token table belongs to the api.
5a319491