Files
notifications-admin/package.json

63 lines
1.7 KiB
JSON
Raw Normal View History

{
"name": "notifications-admin",
"version": "0.0.1",
"description": "Admin front end for GOV.UK Notify",
"engines": {
"node": ">=10.15.3"
},
"scripts": {
2019-05-21 10:56:38 +01:00
"test": "gulp lint && jest --config tests/javascripts/jest.config.js tests/javascripts",
"test-watch": "jest --watch --config tests/javascripts/jest.config.js tests/javascripts",
"build": "gulp",
"watch": "gulp watch"
},
"repository": {
"type": "git",
"url": "git+https://github.com/alphagov/notifications-admin.git"
},
"author": "Government Digital Service",
"license": "MIT",
"homepage": "https://github.com/alphagov/notifications-admin#readme",
"dependencies": {
"@babel/core": "7.4.0",
"@babel/preset-env": "7.4.2",
Support registering a new authenticator 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]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/server.py [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/static/register.html [3]: https://github.com/alphagov/notifications-admin/blob/91453d36395b7a0cf2998dfb8a5f52cc9e96640f/app/assets/javascripts/updateContent.js#L33 [4]: https://stackoverflow.com/questions/55971593/navigator-credentials-is-null-on-local-server [5]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/rpid.py#L69 [6]: https://stackoverflow.com/questions/12394622/does-jquery-ajax-or-load-allow-for-responsetype-arraybuffer
2021-05-07 18:10:07 +01:00
"cbor-js": "0.1.0",
"del": "5.1.0",
"govuk_frontend_toolkit": "8.1.0",
"govuk-elements-sass": "3.1.2",
"govuk-frontend": "2.13.0",
"gulp": "4.0.2",
"gulp-add-src": "1.0.0",
"gulp-babel": "8.0.0",
"gulp-better-rollup": "4.0.1",
"gulp-clean-css": "4.3.0",
"gulp-concat": "2.6.1",
"gulp-include": "2.4.1",
"gulp-sass": "5.0.0",
"gulp-uglify": "3.0.2",
Add a page to manage a service’s whitelist 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. https://github.com/alphagov/digitalmarketplace-frontend-toolkit/blob/434ad307913651ecb041ab94bdee748ebe066d1a/toolkit/templates/forms/list-entry.html 2. https://github.com/alphagov/digitalmarketplace-frontend-toolkit/blob/434ad307913651ecb041ab94bdee748ebe066d1a/toolkit/scss/forms/_list-entry.scss 3. https://github.com/alphagov/digitalmarketplace-frontend-toolkit/blob/434ad307913651ecb041ab94bdee748ebe066d1a/toolkit/javascripts/list-entry.js 4. http://twitter.github.io/hogan.js/
2016-09-20 12:30:00 +01:00
"hogan": "1.0.2",
"jquery": "3.5.0",
"leaflet": "1.6.0",
"morphdom": "2.6.1",
"query-command-supported": "1.0.0",
"rollup": "1.23.1",
"sass": "1.32.7",
"streamqueue": "1.1.2",
"textarea-caret": "3.1.0",
"timeago": "1.6.5"
},
"devDependencies": {
2016-02-23 10:56:48 +00:00
"gulp-css-url-adjuster": "0.2.3",
"gulp-jshint": "2.1.0",
"gulp-prettyerror": "2.0.0",
"gulp-sass-lint": "1.4.0",
2019-04-12 11:51:51 +01:00
"jest": "24.7.1",
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
"jest-date-mock": "^1.0.8",
"jest-each": "^25.3.0",
2019-04-01 16:41:23 +01:00
"jshint": "2.10.2",
"jshint-stylish": "2.2.1",
"rollup-plugin-commonjs": "10.1.0",
"rollup-plugin-node-resolve": "5.2.0"
}
}