this ensures it's reusable by other components, and easier to unit test
by isolating the separate concerns
note: this is not in Modules since that's designed for classes that are
then bound to an element in the DOM as indicated by a data-module
attribute. This will just live at the window.GOVUK level since we want
there to only ever be one `.banner-dangerous` warning.
Makes the controls and links inside it match GOVUK
Frontend styles and:
- gives the map container a focus style matching
that for GOVUK Frontend text inputs
- makes it all work in high contrast modes (on
Windows and Firefox)
Note: the focus style for the container is applied
with :focus-visible so only appears when it gets
focus directly, not when it does due to child
elements (like the controls or links) getting
focused. Browsers without support for
:focus-visible get the same styling for all forms
of focus.
if user has `webauthn_auth` as their auth type, then redirect them to an
interstitial that prompts them to click on a button which right now just
logs to the JS console, but in a future commit will open up the webauthn
browser prompt
content is unsurprisingly not final.
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.
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.
In very old browsers it used to be that you could only make 2 concurrent
requests from the same origin.
So base64 encoding of images into CSS was an optimisation that became
popular because it reduced the number of separate requests.
However base64 encoding images has a few disadvantages:
- it increases the size of the image by about 30%
- it increases the size of the CSS file, which is a
[render blocking resource](https://web.dev/render-blocking-resources/)
so makes the page appear to load more slowly for the sake of some
images which, on most pages, never get used
- GZipping things that are already compressed (for example PNG data) is
very CPU intensive, and might be why Cloudfront sometimes gives up
Removing the inlining of images reduces the size of the CSS we’re
sending to the browser considerably:
–| Before | After | Saving
---|---|---|---
Uncompressed | 198kb | 164kb | 17%
Compressed | 38kb | 23kb | 39%
Cloudfront, our CDN, sometimes decides not to gzip
assets. Because of this, we're going to gzip them
ourselves prior to upload instead.
This will involve:
1. adding gzipping to the make task that uploads
them
2. turning compression off in Cloudfront
There is already a pull request up for number 1:
https://github.com/alphagov/notifications-admin/pull/3733
Because deploying all this will, at some point,
create a state where Cloudfront is set to compress
assets that are already compressed, we need to
test that it doesn't re-compress them.
This adds a frontend build task that generates a
test asset which is:
- a copy of app/static/stylesheets/main.css
- renamed to include a MD5 SHA of its contents
- already gzipped
Once deployed, the test will be to:
1. download the asset from the live environment
2. unzip it
3. diff it against app/static/stylesheets/main.css
We write our Sass to be mobile-first, meaning we
declare the value for a property (for mobile) and
then add all other variations (for other
viewports) afterwards.
Because of this, we need mixins that produce media
queries to be able to follow declarations.
This extension to the rule is also hinted at as
good practice in the docs:
7847511b61/docs/rules/mixins-before-declarations.md
Leaflet seems to be the go-to library for rendering maps these days. It
will be useful for the broadcast work.
This commit add the leaflet Javascript and CSS to our asset pipeline.
The Javascript is already minified so all we need to do is copy it. The
CSS is uncompressed so we put it through the same pipe as our other
stylesheets.
I’m keeping these as separate files because they’re quite heavy (or the
JS is at least – 38kb minified) so I want them to only be loaded on the
pages where they’re used. Most users of Notify will never need to see a
map.
Includes:
- new content
- added option to turn analytics on/off
- non-js version for the on/off switch
- a banner to confirm user's choice was saved,
shown when they click the save button
- the cookie banner that appears on all other
pages removed from this page
Includes:
- new content
- added option to turn analytics on/off
- non-js version for the on/off switch
- a banner to confirm user's choice was saved,
shown when they click the save button
- the cookie banner that appears on all other
pages removed from this page
Includes:
- in gulpfile.js:
- add details macro to list of those copied from GOVUK Frontend
- remove existing details polyfill
- convert all, but one, <details> tags to use GOVUK Frontend details component
- add jinja boolean filter to help setting 'open' attribute of <details> tags
Notes on the `<details>` not included in this:
The `<details>` used for notifications items on
the API integration page is not possible to
reproduce with the GOV.UK Frontend macro so I'm
splitting the resulting work out into it's own
commit.
Their priority should always add up to 100%. Currently we have to ensure
this by hand. Adding this form means there’s no way to not set their
combined priorities to 100%. And it’s a bit more of an intuitive UI than
two textboxes on separate pages.
Includes:
- in gulpfile.js:
- add details macro to list of those copied from GOVUK Frontend
- remove existing details polyfill
- convert all, but one, <details> tags to use GOVUK Frontend details component
- add jinja boolean filter to help setting 'open' attribute of <details> tags
Notes on the `<details>` not included in this:
The `<details>` used for notifications items on
the API integration page is not possible to
reproduce with the GOV.UK Frontend macro so I'm
splitting the resulting work out into it's own
commit.
`node_modules` isn't included on live so all
macros need copying across into the repo' code.
This adds the back-link component to the list of
macros to be copied across in `gulpfile.js`.
It also adds the files copied across as a result
of running the frontend build into the repo'.
Fix for issue that caused this revert:
https://github.com/alphagov/notifications-admin/pull/3196
Note:
gulp-css-url-adjuster operates on an Abstract
Syntax Tree (AST) derived from `main.css`. The
CSS output from this loses the compression
gulp-sass applies.
This moves compression out of Sass, to a step
after the URLs are adjusted.
`node_modules` isn't available in a live
environment so the `.njk` templates we're now
using from GOVUK Frontend need to go in the repo'
code.
Adds them in a new `app/templates/vendor` folder
to match how we do that in
`app/assets/stylesheets`.
Means our rollup bundling doesn't leave any
artefact files lying around that we'd then have to
deal with.
Also includes:
- removal of some JSHint config' marking the
artefacts as scripts to ignore
- use of streamqueue package to allow the same
ordering of scripts as before
It's not obvious how the code that includes JS
Modules in the frontend build works.
This adds lots of comments to explain the various
bits and flattens `modules/all.mjs` to just be a
single function that starts off the window.GOVUK
namespace.
Also removes `module/all.js` from the repo'. It's
an artefact used by the frontend build so
shouldn't be included as source code.
Includes Sass that targeted GOV.UK Template HTML
and also moves some link styles to `globals.scss`.
Also removes bits of frontend build that copied
over GOVUK Template files.
The cookie_message block was part of GOV.UK
template but is not included in the GOV.UK
Frontend template.
This adds it back in along with JS to set the
cookies from GOV.UK template and styles, taken
from the Design System's website (which I assume
has the right colour contrast).
This includes the JS for all GOV.UK Frontend code.
If our frontend build includes a module bundler in
future, we should only include the JS for the
components we use, as with our Sass.
`node_modules` isn't available in a live
environment so the `.njk` templates we're now
using from GOVUK Frontend need to go in the repo'
code.
Adds them in a new `app/templates/vendor` folder
to match how we do that in
`app/assets/stylesheets`.
Means our rollup bundling doesn't leave any
artefact files lying around that we'd then have to
deal with.
Also includes:
- removal of some JSHint config' marking the
artefacts as scripts to ignore
- use of streamqueue package to allow the same
ordering of scripts as before
It's not obvious how the code that includes JS
Modules in the frontend build works.
This adds lots of comments to explain the various
bits and flattens `modules/all.mjs` to just be a
single function that starts off the window.GOVUK
namespace.
Also removes `module/all.js` from the repo'. It's
an artefact used by the frontend build so
shouldn't be included as source code.
