This moves the back link to be above the `<main>` tag by making use of
the new `backLink` block. This doesn't change the pages which are using
a back link as part of the `page_header` macro yet.
When referring to something that’s not part of the Notify system, like a
spreadsheet or a paper letter or a security key we’ve found it’s helpful
to give people a visual representation of it. This commit does the same
for security keys.
This scopes the check for WebAuthn API to the page where we need
it, which will slightly reduce load times for other pages. Since
we want this script to execute ASAP, I've added a new block for
extra JS to run at the start of the body.
This hides the "Register" button and shows an error that's specific
to one of two ways a browser may not support WebAuthn:
- JavaScript is disabled (there's no possible fallback for this).
- WebAuthn API is not supported (e.g. on Internet Explorer).
We could add a similar check for the API in the JS code to handle
the button click, but hiding it seems like enough protection.
In order to avoid elements flashing when the page loads, this uses
a view macro to embed a script at the start of the body element,
which is the same approach used for the "js-enabled" class flag [1].
Tested with Chrome and IE 11.
[1]: https://github.com/alphagov/govuk-frontend/blob/main/src/govuk/template.njk#L31
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.
