- to capture the counts of things that we do
- initial commit captures when we create an email or sms
DOES NOT know about ultimate success only that we asked our partners to ship the notification
Requires some updates when we retry sending in event of error.
This uses the `format_phone_number` method from utils to output phone numbers
in a consistent format. It is added to the schemas, so will be applied before
the API tries to do anything with a provided phone number.
So now the API will accept any of the following:
- 07123456789
- 07123 456789
- 07123-456-789
- 00447123456789
- 00 44 7123456789
- +447123456789
- +44 7123 456 789
- +44 (0)7123 456 789
…but the API will always hand off phone numbers to 3rd party APIs in the format
- +447123456789
The test for this is slightly convoluted, because template IDs are still
database IDs, and can’t consistently be mocked, therefore we have to ignore that
part of the call to `encrypt()`.
This was added to utils in 5914da74f1
This means that:
- we are doing the exact same validation in the API and admin app
- we are actually validating phone numbers for the correct format (hence all the
changes to the tests)
Templates are created in the admin app and persisted in the API.
They are consumed:
- in the admin app, by requesting them from the API
- in the API, by loading them from the database
There are two potential places where unescaped HTML could be sent to a user:
- when the admin app is previewing a template (it has to render the template as
markup in order to show the placeholders)
- in the body of an email
For all consumers to have confidence that the templates are safe, it makes sense
to santitise them at the point of creation (and modification). This also avoids
any performance issues that could come from doing it at the point of requesting
a template.
In the future they could be created by a direct API call, bypassing the admin
app. Therefore it makes sense for the API to sanitise them.
The commit sanitises templates using a Mozilla’s Bleach library[1]. It is
configured to get the text content of the template, minus any HTML tags. It is
not using a regex because[2].
1. https://github.com/mozilla/bleach
2. http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454
Templates are created in the admin app and persisted in the API.
They are consumed:
- in the admin app, by requesting them from the API
- in the API, by loading them from the database
There are two potential places where unescaped HTML could be sent to a user:
- when the admin app is previewing a template (it has to render the template as
markup in order to show the placeholders)
- in the body of an email
For all consumers to have confidence that the templates are safe, it makes sense
to santitise them at the point of creation (and modification). This also avoids
any performance issues that could come from doing it at the point of requesting
a template.
In the future they could be created by a direct API call, bypassing the admin
app. Therefore it makes sense for the API to sanitise them.
The commit sanitises templates using an XML parser. It extracts the text content
of the template, minus any HTML tags, because of this famous StackOverflow
answer:
http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454
- include travis build number
- renamed properties
- ELB version
- moved code all into health check
- changed health check to be on same URL for admin and api
This is checked on 3rd party API calls, but jobs (CSV files) were able expected to only allow valid files.
Change in tack means we want to have restricted notification failures reported in the UI.
When building the template it was looking for a placeholder called
((phone number)). This caused it to fail because the template it had did not
match the personalisation it was being given.
`Template` has an optional parameter for specifying personalisation values that
should be ignored. The recipient of a message is an example of such a value.
This commit passes that extra parameter, which fixes that bug.
