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.
I saw users in research going back into the whitelist to check that it
had saved because there’s no feedback.
This commit adds a flash message to confirm that the whitelist was saved
OK.
Why would a live servie need the whitelist? Because the team key will
also let you send to members of your whitelist (so this commit relabels
it to say so).
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.
Platform admins should be able to see what’s going on with a service’s
API integration, including:
- messages sent
- contents of whitelist
- names of keys
They should also be able to revoke keys in an emergency.
The only thing they _shouldn’t_ be able to do is create new keys
(because then they’d be able to send messages as the service).
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.
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/
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
```
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.
If you have scheduled and then cancelled jobs this would be enough to
show the jobs block on the dashboard (in otherwords it wasn’t filtering
out cancelled jobs). However the contents of the table _were_ filtering
out cancelled jobs, so the table would be empty and look broken.
This commit changes the conditional to operate on the `list` of jobs
with cancelled ones filtered out.
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
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
If a job is scheduled then we can’t show the notifications yet, and the
progress report will stay at 0%.
In their place we should show what time a job will start.
Later on (when the API is ready) this area of the page should also show
a cancel button.
On the dashboard:
- adds a new ‘in the next 24 hours’ section to the dashboard which lists
upcoming jobs
- tweaks some spacing on the dashboard so that it doesn’t look like too
much of a mess
- don’t show scheduled jobs in the table of normal jobs
On the jobs page:
- don’t show scheduled jobs
Users need to pick a time in the next 24hrs, or send a file immediately.
Rationale for this is a bit lost in time-before-holiday, but generally:
‘Now’ and ‘later’ as the inital choices makes it really clear what
this feature is about conceptually.
The choice of times is absolute, eg ‘1pm’ not ‘in 3 hours’
