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
Starting arguments on their own line and putting the closing parenthesis
on it’s own line because any subsequent changes to the arguments diff
cleanly (ie without touching any other lines).
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 is like the ‘pill’ pattern that we use for filtering lists of
notifications. However it is meant for navigating between discrete
things, not a filtered view of the same list.
This is why is has a gutter between each item, and no selected state.
Turns out we already had a pattern about this on the dashboard, so this
commit also changes the dashboard to use the same code.
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.
Pages that don’t have navigation shouldn’t extend the top-level admin
template directly.
They should extend `withoutnav_template.html` instead, because then they
get a wrapping `<main>` element, which is good semantically and for
accessibility, and also defaults the font size to `19px`.
- 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
```
We see over and over in research that people are tripped up by the 10
character requirement because it’s longer than they are used to. Most
sites require 6 or 8 characters for a password.
It goes against the CESG advice which is to not try increasing password
strength by increasing the burden on the user:
> Traditionally, organisations impose rules on the length and complexity
> of passwords. However, people then tend to use predictable strategies
> to generate passwords, so the security benefit is marginal while the
> user burden is high.
https://www.cesg.gov.uk/guidance/password-guidance-simplifying-your-approach
Instead we should be relying on:
- [x] two factor authentication
- [x] blacklisting common passwords
- [ ] locking out users after a number of failed logins (not sure this
is working)
We have a route at /_email for testing the email template.
This commit adds:
- ordered lists
- a URL
And it fixes:
- the unordered list (markdown requires two line break before starting
a list)
This is so that we can test how these features look locally without
having to send an email.
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.
Since we’re going to have spearate tables for live and trial mode
services it saves copying and pasting to have a macro for them. Not
worth completely factoring out into a component because it’s only going
to be used on this page.
