if you log a dictionary, python-json-logger will pass that through to
the json output. In the ip restriction wrapper, lets log the ip_address
and whether it was found in the whitelist, to a nested `log_contents`
dict.
when logging json, it looks like this:
{"name": "app", "levelname": "INFO", "message": "Logging configured", "pathname": "/Users/leohemsted/.virtualenvs/api/lib/python3.5/site-packages/notifications_utils/logging.py", "lineno": 98, "log_contents": {"thing": 1, "foo": "bar"}, "requestId": "no-request-id", "time": "2017-07-31T18:09:39", "application": "api", "logType": "application"}
when logging via stdout locally, it looks like this:
2017-07-31T18:11:31 api app INFO no-request-id "{'log_contents': {'foo': 'bar', 'thing': 1}, 'message': 'Logging configured'}" [in /Users/leohemsted/.virtualenvs/api/lib/python3.5/site-packages/notifications_utils
We can then use this later - saving an extra DB query on every client facing API call
- Note this doesn't affect admin calls which do not use the service from the api key, but use the one passed as part of the URL path.
There are three authentication methods:
- requires_no_auth - public endpoint that does not require an Authorisation header
- requires_auth - public endpoints that need an API key in the Authorisation header
- requires_admin_auth - private endpoint that requires an Authorisation header which contains the API key for the defined as the client admin user
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.
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
moved from notifications/rest -> service/rest and job/rest respectively
endpoint routes not affected
removed requires_admin decorator - that should be set by nginx config
as opposed to python code
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.
