You can’t properly use a normal key when your service is in trial mode.
It’s theoretically useful to create a live key in preparation for going
live. This utitily outweighs the confusion it causes for people creating
their first keys in trial mode.
We should just remove the confusing option.
Basically:
- shows all the months from start of given financial year to now or end
of given financial year (whichever is earliest)
- shows a breakdown of free and paid text messages for each of these
months
Depends on:
- [x] https://github.com/alphagov/notifications-api/pull/699
The activity page was AJAXified in
https://github.com/alphagov/notifications-admin/pull/952 but this
didn’t take pagination into account.
So if you visited page 2, the contents of the page would be replaced by
Javascript with the contents of page 1. So you’d never be able to see
anything beyond page 1, expect for a brief fraction of a second when the
page loaded.
This commit makes sure the AJAX request uses whatever page parameter is
in the URL of the original page.
Now that we’ve removed simulated notifications from the dashboard and
activity pages they’re not visible anywhere in the app.
While they should’t be visible to non-technical users, developers have
a real need for Notify to confirm that their code is doing what they
expect. This is needed especially when they’re just getting started with
Notify.
There’s no way of seeing this info from the API either, because a key
can only get notifications created with a key of that type.
It doesn’t make sense to make this a ‘mode’ of the dashboard or activity
because the information about notifications that developers need is
also different. So this commit adds up to 50 of the most recent
notifications sent via the API to the page that developers use as their
‘home’ page.
This also lets us explain the 7 days thing to developers via the
empty slate state of this area of the page.
We want to show a log of notifications that have been sent from the API.
The admin app uses its own private `/service/…/notifications` endpoint
for listing activity. This commit allows us to pass through two
optional, additional parameters to tell the API to:
- include or not include notifications created from a job
- include or not include notifications created with a test API key
Services who are in alpha or building prototypes need a way of sending
to any email address or phone number without having to sign the MOU.
This commit adds a page where they can whitelist up to 5 email addresses
and 5 phone numbers.
It uses the ‘list entry’ UI pattern from the Digital Marketplace
frontend toolkit [1] [2] [3].
I had to do some modification:
- of the Javascript, to make it work with the GOV.UK Module pattern
- of the template to make it work with WTForms
- of the content security policy, because the list entry pattern uses
Hogan[1], which needs to use `eval()` (this should be fine if we’re
only allowing it for scripts that we serve)
- of our SASS lint config, to allow browser-targeting mixins to come
after normal rules (so that they can override them)
This commit also adds a new form class to validate and populate the two
whitelists. The validation is fairly rudimentary at the moment, and
doesn’t highlight which item in the list has the error, but it’s
probably good enough.
The list can only be updated all-at-once, this is how it’s possible to
remove items from the list without having to make multiple `POST`
requests.
1. 434ad30791/toolkit/templates/forms/list-entry.html
2. 434ad30791/toolkit/scss/forms/_list-entry.scss
3. 434ad30791/toolkit/javascripts/list-entry.js
4. http://twitter.github.io/hogan.js/
We’ve found in research that developers have no idea they’re in trial
mode until they hit an error. And even then they don’t really know what
trial mode means.
So this commit:
- adds a message to the API integration page about trial mode
- puts it in a really yellow banner to draw attention to it
- adds the same banner to the settings page
This commit adds a placeholder page which, for now, just has links to
the API keys page and links to the clients.
There’s more stuff to come on this page, but this commit just does the
reorganising so that it’s easier to review.
- it tried to send a verify code which no longer is applicable
- one stage of process removed and tests update properly
Flow is:
- Change email
- Confirm with password
- Done
There’s a chance that someone will run out of imagination and use
the name of the thing they’re signing up for as their password.
This wouldn’t be caught by the generic blacklist.
If a user chooses a very common password then an attacker could guess it
in relatively few attempts, circumventing the lockout.
CESG recommend blacklisting the most common passwords:
> …enforcing the requirement for complex character sets in passwords is
> not recommended. Instead, concentrate efforts on technical controls,
> especially:
>
> - defending against automated guessing attacks by either using account
> lockout, throttling, or protective monitoring
> - blacklisting the most common password choices
How I made this list:
- went to the OWASP repository of security lists:
https://github.com/danielmiessler/SecLists
- downloaded `10k_most_common.txt`, `twitter-banned.txt` and
`500-worst-passwords.txt`
- filtered out any under 8 characters:
```
sed -r '/^.{,7}$/d' passwords-twitter.txt > passwords-combined.txt
sed -r '/^.{,7}$/d' passwords-500.txt >> passwords-combined.txt
sed -r '/^.{,7}$/d' passwords.txt >> passwords-combined.txt
```
- filtered out any duplicates:
```
cat passwords-combined.txt | awk '!x[$0]++' > passwords-combined-deduped.txt
```
Other than which services are live it’s also interesting to know what
services are getting created on Notify. So let’s put the newest ones at
the top of the page.
This commit changes the tables of notifications from 3 columns to two
columns. This is so the text has more room, so it doesn’t start
overlapping.
It also makes sure that if the recipient gets really long that it will
be cut off with an ellipsis, rather than overlapping…
I hypothesize that if a notification fails you probably don’t care when
it failed, just that it failed.
I was using the trial mode page to prototype the time picker as part of
225a61ddd3.
I didn’t clean up properly, and left an errant undefined variable, which
caused the trial mode page to `500`.
This commit:
- removes the errant argument
- adds a test for all the static pages to make sure that they at least
return a `200`
If you schedule a job you might change your mind or circumstances might
change. So you need to be able to cancel it. This commit adds a button
on the job page which hits the `…/cancel` API endpoint for a job.
The information about a job doesn’t make sense if a job is cancelled.
We could change the information to reflect that the job won’t be sent/
wasn’t sent/was cancelled, but there’s nothing you can really do with
this info.
So instead let’s:
- hide cancelled jobs from the dashboard
- hide cancelled jobs from the jobs page
- 404 the page if the user tries to click back enough times to hit the
job page
The create job endpoint returns the data about the job with a `data:`
wrapper. This commit makes sure that, when the client is trying to
process a job which has just been created, it looks inside the `data`
wrapper.
For two reasons:
- it’s extra stuff in tour that users dont yet need to know about
- test messages are hidden from the dashboard, so you’d have no
visibility of when they were sending once you’d scheduled them
