hypothesis / h / 10255

70%

master: 97%

push

travis-ci

Add simple, long-lived API tokens

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 ... (continued)

62 of 62 new or added lines in 8 files covered. (100.0%)

2740 of 3896 relevant lines covered (70.33%)

0.7 hits per line