moved api_key secret manipulation (generating and getting) into
authentiation/utils, and added a property on the model, to facilitate
easier matching of authenticated requests and the api keys they used
* single-column static data table that currently contains two types: 'normal' and 'team'
* key_type foreign-keyed from api_keys
- must be not null
- existing rows set to 'normal'
* key_type foreign-keyed from notifications
- nullable
- existing rows set to null
* api_key foreign-keyed from notifications
- nullable
- existing rows set to null
The only update we should be doing to an api key is to expire/revoke the api key.
Removed the update_dict from the the save method.
Added an expire_api_key method that only updates the api key with an expiry date.
This version of the client removed the request method, path and body from the encode and decode methods.
The biggest changes here is to the unit tests.
The change is backward compatible so an older client that sends a jwt with the extra claims will pass authentication.
Once all the clients have been updated to not include the extra claims some updates to exclude them from the method signatures will happen as well.
Ideally all the primary keys in the db would be UUID in order to guarantee unique ids across distributed dbs.
This updates the services.id to a UUID. All the tables with a foreign key to the services.id are also updated.
The endpoints no longer state a data type of the <service_id> path param.
All the tests are updated to reflect this update.
The thing to pay attention to is the 0011_uuid_service_id.py migration script.
This commit must go with a commit on the notifications_admin app to keep things working.
There will be a small outage until both deploys have happened.
/service/<service_id>/api-key/renew has been renamed to /service/<service_id>/api-key
/service/<service_id>/api-key now creates a token and no longer expires the existing api key.
Moved test for this endpoint to it's own file.
