This follows the same approach as for window.fetch, using the Jest
before/afterAll() blocks to handle the idiosynchrosies of whether
the object/function is defined in the test environment.
This adds Yubico's FIDO2 library and two APIs for working with the
"navigator.credentials.create()" function in JavaScript. The GET
API uses the library to generate options for the "create()" function,
and the POST API decodes and verifies the resulting credential. While
the options and response are dict-like, CBOR is necessary to encode
some of the byte-level values, which can't be represented in JSON.
Much of the code here is based on the Yubico library example [1][2].
Implementation notes:
- There are definitely better ways to alert the user about failure, but
window.alert() will do for the time being. Using location.reload() is
also a bit jarring if the page scrolls, but not a major issue.
- Ideally we would use window.fetch() to do AJAX calls, but we don't
have a polyfill for this, and we use $.ajax() elsewhere [3]. We need
to do a few weird tricks [6] to stop jQuery trashing the data.
- The FIDO2 server doesn't serve web requests; it's just a "server" in
the sense of WebAuthn terminology. It lives in its own module, since it
needs to be initialised with the app / config.
- $.ajax returns a promise-like object. Although we've used ".fail()"
elsewhere [3], I couldn't find a stub object that supports it, so I've
gone for ".catch()", and used a Promise stub object in tests.
- WebAuthn only works over HTTPS, but there's an exception for "localhost"
[4]. However, the library is a bit too strict [5], so we have to disable
origin verification to avoid needing HTTPS for dev work.
[1]: c42d9628a4/examples/server/server.py
[2]: c42d9628a4/examples/server/static/register.html
[3]: 91453d3639/app/assets/javascripts/updateContent.js (L33)
[4]: https://stackoverflow.com/questions/55971593/navigator-credentials-is-null-on-local-server
[5]: c42d9628a4/fido2/rpid.py (L69)
[6]: https://stackoverflow.com/questions/12394622/does-jquery-ajax-or-load-allow-for-responsetype-arraybuffer
This adds a new platform admin settings row, leading a page which
shows any existing keys and allows a new one to be registered. Until
the APIs for this are implemented, the user API client just returns
some stubbed data for manual testing.
This also includes a basic JavaScript module to do the main work of
registering a new authenticator, to be implemented in the next commits.
Some more minor notes:
- Setting the headings in the mapping_table is necessary to get the
horizontal rule along the top (to match the design).
- Setting caption to False in the mapping_table is necessary to stop
an extra margin appearing at the top.
The fieldset that wraps the collapsible checkboxes
has an aria-describedby to make the summary its
accessible description.
This needs to point to the id of the summary but
the summary didn't have one.
These changes add the id and fix a fixture in the
tests for this module.
Includes changing the code so that the radios
aren't split into two columns in the HTML present
when the page loads. This layout is now added by
the JS.
After talking with the reviewer, it was decided
that:
1. the JS could do with some comments to explain
its structure and what various functions do
better
2. some CSS selectors in the tests don't need to
be as complex and simplifying them makes the
test easier to read
Makes focus shift to the first time in the range
when you select a day.
Also rewrites the code for controlling focus so it
explains itself better, now it has different
settings.
All buttons that open or close a region of the
component should have aria-expanded attributes to
show:
- they have that control
- the state of the region
jQuery.attr returns `undefined` if an element does not have an
attribute. We want an empty string, rather than the default of coercing
`undefined` to the string `'undefined'`.
The `<textarea>` should have its existing `aria-describedby` point to a
hint. Pointing to the label is bad practice as it would duplicate the
accessible name into the accessible description. It’s good not to have
that in the tests in case anyone copies the code elsewhere.
The endpoint that count characters should be pretty low-load because it
won’t talk to the database (unless, on the first request, the user and
service aren’t cached in Redis).
The response size is also very small, only one line of text wrapped in a
single `<span>`, so won’t be as CPU-intensive to render as a whole page.
Still, we don’t want to completely hammer the server if a user types
very quickly.
This commit adds some throttling, so that we wait until there’s a
certain amount of delay between keystrokes before firing off the request
to the backend.
I’ve set the delay at 150ms. At normal typing speed this makes the lag
feel fairly imperceptible – it feels like you get an updated count in
response to most keystrokes. It’s only if you really mash the keyboard
that the count won’t update until you take a breath.
This commit copies the same ARIA attributes that are added to the
character count component[1] in the GOV.UK Design System.
This means that screen reader users will hear the count message when
they stop typing.
1. https://design-system.service.gov.uk/components/character-count/
This commit adds some Javascript that makes AJAX requests as the users
changes the content of their template.
It then takes the content returned by the backend and inserts it in the
page.
Includes a change to make these tests use the
getRadioGroup helper to reduce duplication across
the tests. This also makes a few changes to the
helper so it can produce the HTML required.
The previewPane JS used selectors that targeted
the old form of radios HTML.
The JS tests also contained selectors like this
and fragments of HTML, used for fixtures, modelled
on the old radios HTML.
Doing this was helpful to Voiceover users as its
announcement of the label meant the page title
(normally announced onload) wasn't skipped.
This isn't the case with JAWS so, prefixing the
title makes it announce it twice.
JAWS has a lot more users and the title being
announced twice is more confusing than not at all
so this removes it.
The existing behaviour focused the form control
for each popup (radios or textbox) when opened.
This gives no indication the submit button or
cancel link have been added to the page.
These changes:
- make the parent element a region to group all
the new content
- label the region to link it to the button that
opened it
- add a description to the region so users know
how to use it and that all the controls have
been added to the page
Suggested by the Digital Accessibility Centre in
their report. Giving these buttons
aria-expanded=false indicates:
- they control a section on the page
- that section is collapsed (and so clicking the
button will open it)
They originals didn't explain what the tests do.
We could test the contents of the range but that
would be testing the Range API, rather than our
use of it.
The tests test how we use that API for these
scenarios so their descriptions should say this.
Since moving textboxes to GOV.UK Frontend we’ve started putting the
data attribute on the `input` element itself, not a wrapper around it.
This commit updates the Javascript accordingly.
ListEntry component uses FieldList field to group
textboxes. Textboxes can be text inputs, email fields
or international phone number fields. This converts
all field-lists to use:
- GovukTextInputField
- GovukEmailField
- InternationalPhoneNumber
Affects these forms:
- OrganisationDomainsForm
- GuestList
Also changes to related Javascript:
Update list-entry JS tests to match new HTML
Updates the HTML the JS operates on in the test
(a fixture representing the HTML in the page on
load) to match the new GOVUK Frontend we are
generating.
Make list-entry JS work with GOVUK Frontend HTML
The existing list-entry JS did a few things that
clashed with how the new HTML works:
- added a 'input-' prefix to the id attributes
of all text-inputs
- did not make its name and id attributes values
match
The new HTML has id and name attributes that
match so these changes remove the prefix for id
attributes and makes them match the name
attribute.
To understand these changes, it is useful to
know how the values for id and name attributes are
generated:
1. the id attribute for the component element is
stored
2. the 'list-entry-' prefix is removed and the
remainder is used to generate ids
For example, if the component's id is
'list-entry-domains', the id will be 'domains-1',
where the text-input is the first one.
This also adds some logic to the HoganJS template
to make the value attribute optional, so it is
only added if it has a non-null value. This
matches the behaviour of the text-input component
used in the new list-entry component.
Also change whitelist references to guestlist in tests
- we forgot to do it earlier, when we moved from calling this
feature whitelist to calling it guestlist.
These tests make sure the sub-categories shown
when a category is selected are right but the
comparison looked for a direct match between the
labels for both types.
This looks for the category label in the
sub-category label instead, ie.
'Today at' in 'Today at 1pm'.
...instead of
'Today at' === 'Today at 1pm', which will always
fail.
Different emergencies will need broadcasts to last for a variable amount
of time. We give users some control over this by letting them stop a
broadcast early. But we should also let them set a maximum broadcast
time, for:
- when the duration of the danger is known
- when the broadcast has been live long enough to alert everyone who
needs to know about it
This code re-uses the pattern for scheduling jobs, which has some
constraints that are probably OK for now:
- end time is limited to an hour
- longest duration is 3 whole days (eg if you start broadcasting Friday
you have the choice of Saturday, Sunday and all of Monday, up to
midnight)
