flake8
passed.
JSHint
passed.
Update the WebAPIToken model for API Tokens v2
Review Request #12342 — Created June 6, 2022 and submitted
This change is the first in a series of changes for improving our API Tokens
(which we'll refer to as API Tokens v2). Currently, Review Board uses a SHA1
token format, which has the following disadvantages:
- Tokens aren't able to be validated or identified from other SHA1 tokens.
- Can't use secret scanning to detect leaked tokens.
- They aren't as secure as some modern counterparts.In response, we are moving towards a new token format that contains a
vendor/category prefix and can be validated through a checksum. Additionally,
we want to be able to support token expiration and invalidation, which we
currently don't do. Since we are moving away from an old token format, we also
need support for token deprecation.In this change we modify the API tokens model to allow the possibility for
new token types, expiration, and invalidation. The following changes are made
to theWebAPITokenmodel:
- Addingexpiresfield
- Addingvalid,invalid_dateandinvalid_reasonfields
- Addingtoken_generator_idfield
- Addinglast_usedfield
- Updating max length of token to 255 characters.
Successfully upgraded the database and successfully created a new database.
| Summary | ID |
|---|---|
| 0885e2b7717e19f9f44a5598ba66d5763281a312 |
| Description | From | Last Updated |
|---|---|---|
|
For database changes, suitable testing would, at a minimum, be to upgrade a database with this evolution, and to create … |
 chipx86
|
|
|
Since this is the starting point for this body of work in Review Board, this would be a good place … |
chipx86
|
|
|
This must be one line. You can put more details in the description. |
chipx86
|
|
|
As mentioned in the generator change, this should be all lowercase (legacy_sha1). Other than that, looks good! |
chipx86
|
- Description:
-
~ Updating the WebAPIToken model for API Tokens v2
~ As part of our move to API Tokens v2, we need to open API tokens for new token
+ types, expiration, and invalidation. The following changes are made to the + WebApiTokenmodel:+ + - Adding expires field
+ - Adding valid, invalid_date and invalid_reason fields
+ - Adding token_generator_id field
+ - Adding last_used field
+ - Updating max length of token to 255 characters.
- Testing Done:
-
~ As part of our move to API Tokens v2, we need to open API tokens for new token
~ None.
- types, expiration, and invalidation. The following changes are made to the - WebApiTokenmodel:- - - Adding expires field
- - Adding valid, invalid_date and invalid_reason fields
- - Adding token_generator_id field
- - Adding last_used field
- - Updating max length of token to 255 characters.
-
-
For database changes, suitable testing would, at a minimum, be to upgrade a database with this evolution, and to create a brand-new database with this change.
-
Since this is the starting point for this body of work in Review Board, this would be a good place to describe the high-level goals of this project, in the description. That'd help down the road with code archaeology, and avoid needing to know the details or any links to the API Tokens v2 project.
-
- Description:
-
~ As part of our move to API Tokens v2, we need to open API tokens for new token
~ types, expiration, and invalidation. The following changes are made to the ~ WebApiTokenmodel:~ This change is the first in a series of changes for improving our API Tokens
~ (which we'll refer to as API Tokens v2). Currently, Review Board uses a SHA1 ~ token format, which has the following disadvantages: + - Tokens aren't able to be validated or identified from other SHA1 tokens. + - Can't use secret scanning to detect leaked tokens. + - They aren't as secure as some modern counterparts. ~ - Adding expires field
~ - Adding valid, invalid_date and invalid_reason fields
~ - Adding token_generator_id field
~ - Adding last_used field
~ - Updating max length of token to 255 characters.
~ In response, we are moving towards a new token format that contains a
~ vendor/category prefix and can be validated through a checksum. Additionally, ~ we want to be able to support token expiration and invalidation, which we ~ currently don't do. Since we are moving away from an old token format, we also ~ need support for token deprecation. + + In this change we modify the API tokens model to allow the possibility for
+ new token types, expiration, and invalidation. The following changes are made + to the WebAPITokenmodel:+ - Adding expiresfield+ - Adding valid,invalid_dateandinvalid_reasonfields+ - Adding token_generator_idfield+ - Adding last_usedfield+ - Updating max length of token to 255 characters. - Testing Done:
-
~ None.
~ Successfully upgraded the database and successfully created a new database.
- Commits:
-
Summary ID 049a3c46ec55f6293fbfca002354c940786ea9c1 5f4d6c8f88aeaa8f1b93d37b1646c4e7c75c72ad
Checks run (2 succeeded)
flake8
passed.
JSHint
passed.
- Change Summary:
-
Updated the initial value for
token_generator_idto the snake case version of LegacySHA1TokenGenerator's ID - Commits:
-
Summary ID 5f4d6c8f88aeaa8f1b93d37b1646c4e7c75c72ad 903a99b4553216fe8f3d757d2f722141e1a9da66
Checks run (2 succeeded)
flake8
passed.
JSHint
passed.