By serialising these straight away we can:
- not go back to the database later, potentially closing the connection
sooner
- potentially cache the serialised data, meaning we don’t touch the
database at all
Two new metrics:
auth_db_connection_duration_seconds (histogram)
wraps the first DB call of post notifications. This includes waiting
to get a connection from the pool, and also making the actual request
to the db to retrieve the service and api keys. (i'm not sure there's
an easy way to separate these two things)
post_notification_json_parse_duration_seconds
wraps parsing the v2 post notifications json parsing and schema
validation. Shouldn't include any async code
- update check_sms_content_char_count to use the SMSTemplate.is_message_too_long function, and updated the error message to align with the message returned by the admin app.
- Update the the code used by version 1 of the api to use the validate_template method.
- I did find a couple of services still using the old api, however, this change should not affect them as I checked the messages being sent and they are not too long.
- We will be sending a message to them to see if they can upgrade.
- Update the log message for authenication to include the URL - makes it easier to track if a service is using version 1 of the api.
This will allow us to accept two different ones and therefore allow us
to rotate the secret that the admin client is sending to the API
Due to how the notifications-python-client throws exceptions, we run
into exactly the same issue with not being able to distinguish if a
`TokenDecodeError` is thrown because the token was encrypted with a
different secret key or if because there was a different error when
decoding. I've copied the TODO from `requires_auth` as this is exactly
the same issue.
I've also added a test case for functionality that was missing for an
out of date admin token (old IAT).
And support this change across our code. Note, this is a halfway step
where it is not a list rather than a string but still only supports a
single secret, ie one item in the list.
This fixes the test in the previous commit and means we will catch other
unexpected jwt errors which are now raised as `TokenError`s and raise an
AuthError based on this.
This will stop us serving 5xx to users when we don't catch an exception.
Also runs make freeze-requirements
The main drive behind this is to allow us to enable http healthchecks on
the `/_status` endpoint. The healthcheck requests are happening directly
on the instances without going to the proxy to get the header properly
set.
In any case, endpoints like `/_status` should be generally accessible by
anything without requiring any form of authorization.
example log line:
```
API AuthError: AuthError({'token': ['Invalid token: signature, api token is not valid']}, 403, service_id=3e1ed7ea-8a05-4b4e-93ec-d7bebfea6cae, api_key_id=None)"
```
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.
