We’ve seen quite a few developers encounter the `Invalid token: expired`
error message when they’re getting started using the Notify API. When
this happens they either raise a support ticket or ask for help on
Slack.
In every case this has been because the clock on their
machine/environment/container isn’t accurate. The error message doesn’t
help them figure this out.
This commit adds extra detail to the error message so they can fix the
problem without having to come to us for help.
cleaned up some auth code to marginally improve efficiency of error checking
and hopefully make it easier to read
fixed some incorrect auth headers in the deactivate tests
If you sign a token with a service ID that doesn’t exist (say, for
example, that you get service ID and API key mixed up) then you get
an error saying that “no API keys exist for the service”. This is wrong
because the service doesn’t even exist.
This commit adds:
- code to check if the service does exist
- a specific error message for this case
The check does mean an extra database call to look up the service.
However this only happens _after_ looping through all the API keys. So
it shouldn’t have a performance implication for anyone using a valid API
key.
If you create a token signed with a service ID that doesn’t exist, you
will get an error (as you should).
However we didn’t have a test that explicitly checks for this. This
commit adds one.
hopefully cleans up code flow and readability [a tiny bit].
raise an AuthException in auth.py, and catch it in errors.py to
save on returning error_repsonse values throughout the function
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.
