darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-05-01 22:51:10 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
cc876194d05c19a68a87bdbed818a954da3bfb91
notifications-admin/app/main/views/api_keys.py

291 lines
10 KiB
Python
Raw Normal View History

Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
from flask import (
Markup,
abort,
flash,
redirect,
render_template,
request,
url_for,
)
Have permissions decorators check user signed in Rather than force us to write the decorators in a specific order let’s just have one decorator call the other. This should make fewer lines of code, and fewer annoying test failures. It also means that the same way of raising a `401` (through the `current_app` method) is used everywhere.
2019-07-01 15:22:08 +01:00
from flask_login import current_user
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
from app import (
api_key_api_client,
current_service,
notification_api_client,
service_api_client,
)
Extract formatters into their own module We have lots of functions for converting various types of data into strings to be displayed to the user somewhere. This commit collects all these functions into their own module, rather than having them cluttering up `app/__init__.py` or buried amongst various other things that have ended up in `app/utils.py`.
2021-01-06 12:12:01 +00:00
from app.formatters import email_safe
Move view function into own file, add test
2016-01-16 10:59:16 +00:00
from app.main import main
Consolidate callback forms and convert them to gov uk frontend We had two identical callback form classes. One for delivery callbacks and one for inbound sms callbacks. Since they did not differ I consolidated them into one CallbackForm class that they both inherited from previously. I also substituted field classes for this form with new fields that cooperate with gov uk frontend.
2020-08-03 15:10:02 +01:00
from app.main.forms import CallbackForm, CreateKeyForm, GuestList
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
from app.notify_client.api_key_api_client import (
KEY_TYPE_NORMAL,
KEY_TYPE_TEAM,
KEY_TYPE_TEST,
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
)
Extract user utility code into own module This provides more room for expansion, and reduces the amount of arbitrary code in the __init__.py file for the new package.
2021-06-09 13:19:05 +01:00
from app.utils.user import user_has_permissions
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
dummy_bearer_token = 'bearer_token_set'
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/api")
remove admin_override from all has_permissions usage as previously pointed out, it's not used anywhere.
2018-03-01 10:30:17 +00:00
@user_has_permissions('manage_api_keys')
Add an index page for the API integration 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.
2016-09-20 11:34:37 +01:00
def api_integration(service_id):
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
callbacks_link = (
Make a service model and use for permissions Having the service floating about as JSON is a bit flakey. Could easily introduce a mistake where you mistype the name of a key and silently get `None`. Also means doing awkward things like `if 'permission' in current_service['permissions']`, whereas for users we can do the much cleaner `user.has_permission()`. So this commit: - introduces a model - adds a `.has_permission` method similar to the one we have for users
2018-07-20 08:43:02 +01:00
'.api_callbacks' if current_service.has_permission('inbound_sms')
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
else '.delivery_status_callback'
)
Add an index page for the API integration 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.
2016-09-20 11:34:37 +01:00
return render_template(
Add log of notifications to API integration page 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.
2016-09-21 10:13:25 +01:00
'views/api/index.html',
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
callbacks_link=callbacks_link,
move status mapping logic to the api client also added tests :angel:
2017-09-20 16:02:15 +01:00
api_notifications=notification_api_client.get_api_notifications_for_service(service_id)
Add an index page for the API integration 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.
2016-09-20 11:34:37 +01:00
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/api/documentation")
remove admin_override from all has_permissions usage as previously pointed out, it's not used anywhere.
2018-03-01 10:30:17 +00:00
@user_has_permissions('manage_api_keys')
Add a separate page for linking to documentation It’s going to get too cluttered to have these links on the API index page.
2016-09-20 11:38:22 +01:00
def api_documentation(service_id):
Updated support views to represent new url structure
2017-11-28 12:00:12 +00:00
return redirect(url_for('.documentation'), code=301)
Add a separate page for linking to documentation It’s going to get too cluttered to have these links on the API index page.
2016-09-20 11:38:22 +01:00
Rename URL to remove term ‘whitelist’ See c31264d4c for rationale. To avoid confusion the codebase should use the same terminology as the UI.
2020-06-12 09:07:29 +01:00
@main.route("/services/<uuid:service_id>/api/whitelist", methods=['GET', 'POST'], endpoint='old_guest_list')
@main.route("/services/<uuid:service_id>/api/guest-list", methods=['GET', 'POST'])
remove admin_override from all has_permissions usage as previously pointed out, it's not used anywhere.
2018-03-01 10:30:17 +00:00
@user_has_permissions('manage_api_keys')
Rename endpoint to remove term ‘whitelist’ See c31264d4c for rationale. To avoid confusion the codebase should use the same terminology as the UI.
2020-06-12 09:03:40 +01:00
def guest_list(service_id):
Rename form objects to remove the term ‘whitelist’ See c31264d4c for rationale. To avoid confusion the codebase should use the same terminology as the UI.
2020-06-12 09:02:40 +01:00
form = GuestList()
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
if form.validate_on_submit():
Rename API client methods to remove term ‘whitelist’ See c31264d4c for rationale. To avoid confusion the codebase should use the same terminology as the UI.
2020-06-12 09:05:26 +01:00
service_api_client.update_guest_list(service_id, {
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
'email_addresses': list(filter(None, form.email_addresses.data)),
Add flake8 linting to project The GDS Way™[1] recommends using Flake8 to lint Python projects. This commit takes the Flake8 config from Digital Marketplace API[2] and removes the bits we don’t need. It changes the `max_complexity` setting to 14, which is the most complex code we have in this repo currently (we shouldn’t be writing code _more_ complex than what we already have). This commit also fixes the errors found by Flake8, which includes 6(!) tests which were never getting run because they had the same names as existing tests. Here is a full list of the errors that were found and fixed: ``` ./app/__init__.py:2:1: F401 're' imported but unused ./app/__init__.py:4:1: F401 'json' imported but unused ./app/__init__.py:8:1: F401 'dateutil' imported but unused ./app/__init__.py:11:1: F401 'flask.escape' imported but unused ./app/__init__.py:41:1: F401 'app.proxy_fix' imported but unused ./app/__init__.py:129:5: F821 undefined name 'proxy_fix' ./app/__init__.py:221:19: F821 undefined name 'highlight' ./app/__init__.py:221:35: F821 undefined name 'JavascriptLexer' ./app/__init__.py:221:54: F821 undefined name 'HtmlFormatter' ./app/config.py:2:1: F401 'datetime.timedelta' imported but unused ./app/event_handlers.py:2:1: F401 'flask_login.current_user' imported but unused ./app/utils.py:11:1: F401 'dateutil.parser' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.two_factor' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.notifications' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.add_service' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.forgot_password' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.inbound_number' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.styleguide' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.organisations' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.letter_jobs' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.verify' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.conversation' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.api_keys' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.send' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.dashboard' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.jobs' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.manage_users' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.sign_in' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.sign_out' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.code_not_received' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.invites' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.platform_admin' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.providers' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.service_settings' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.index' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.new_password' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.user_profile' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.feedback' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.choose_service' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.templates' imported but unused ./app/main/__init__.py:5:1: F401 'app.main.views.register' imported but unused ./app/main/forms.py:12:1: F401 'wtforms.SelectField' imported but unused ./app/main/views/api_keys.py:37:29: E241 multiple spaces after ':' ./app/main/views/feedback.py:3:1: F401 'flask.flash' imported but unused ./app/main/views/feedback.py:122:17: E123 closing bracket does not match indentation of opening bracket's line ./app/main/views/inbound_number.py:1:1: F401 'flask.url_for' imported but unused ./app/main/views/inbound_number.py:1:1: F401 'flask.session' imported but unused ./app/main/views/inbound_number.py:1:1: F401 'flask.redirect' imported but unused ./app/main/views/inbound_number.py:1:1: F401 'flask.request' imported but unused ./app/main/views/inbound_number.py:13:1: F401 'flask.jsonify' imported but unused ./app/main/views/jobs.py:31:1: F401 'app.utils.get_template' imported but unused ./app/main/views/letter_jobs.py:1:1: F401 'datetime' imported but unused ./app/main/views/letter_jobs.py:6:1: F401 'app.format_datetime_24h' imported but unused ./app/main/views/manage_users.py:111:9: E123 closing bracket does not match indentation of opening bracket's line ./app/main/views/notifications.py:121:5: F841 local variable 'status_args' is assigned to but never used ./app/main/views/organisations.py:1:1: F401 'flask.request' imported but unused ./app/main/views/service_settings.py:77:9: E123 closing bracket does not match indentation of opening bracket's line ./app/main/views/service_settings.py:82:9: E123 closing bracket does not match indentation of opening bracket's line ./app/main/views/service_settings.py:420:13: E123 closing bracket does not match indentation of opening bracket's line ./app/main/views/sign_in.py:12:1: F401 'flask_login.confirm_login' imported but unused ./app/main/views/sign_in.py:17:1: F401 'app.service_api_client' imported but unused ./app/main/views/sign_in.py:62:13: E123 closing bracket does not match indentation of opening bracket's line ./app/main/views/templates.py:4:1: F401 'flask.json' imported but unused ./app/main/views/templates.py:17:1: F401 'notifications_utils.formatters.escape_html' imported but unused ./app/main/views/templates.py:23:1: F401 'app.utils.get_help_argument' imported but unused ./app/main/views/templates.py:64:13: E123 closing bracket does not match indentation of opening bracket's line ./app/notify_client/service_api_client.py:6:1: F401 '.notification_api_client' imported but unused ./app/notify_client/user_api_client.py:1:1: F401 'uuid' imported but unused ./app/notify_client/user_api_client.py:3:1: F401 'flask.session' imported but unused ./tests/__init__.py:1:1: F401 'csv' imported but unused ./tests/app/main/test_asset_fingerprinter.py:2:1: F401 'os' imported but unused ./tests/app/main/test_asset_fingerprinter.py:4:1: F401 'unittest.mock' imported but unused ./tests/app/main/test_asset_fingerprinter.py:98:9: F841 local variable 'string_with_unicode_character' is assigned to but never used ./tests/app/main/test_errorhandlers.py:2:1: F401 'flask.url_for' imported but unused ./tests/app/main/test_permissions.py:26:13: F841 local variable 'response' is assigned to but never used ./tests/app/main/test_placeholder_form.py:3:1: F401 'wtforms.Label' imported but unused ./tests/app/main/test_placeholder_form.py:11:10: F841 local variable 'req' is assigned to but never used ./tests/app/main/test_two_factor_form.py:10:67: F841 local variable 'req' is assigned to but never used ./tests/app/main/test_two_factor_form.py:23:65: F841 local variable 'req' is assigned to but never used ./tests/app/main/test_two_factor_form.py:37:48: F841 local variable 'req' is assigned to but never used ./tests/app/main/test_two_factor_form.py:51:67: F841 local variable 'req' is assigned to but never used ./tests/app/main/test_two_factor_form.py:65:67: F841 local variable 'req' is assigned to but never used ./tests/app/main/views/test_accept_invite.py:356:5: F841 local variable 'element' is assigned to but never used ./tests/app/main/views/test_activity.py:11:1: F811 redefinition of unused 'mock_get_notifications' from line 11 ./tests/app/main/views/test_activity.py:18:1: F401 'datetime.datetime' imported but unused ./tests/app/main/views/test_activity.py:102:5: F841 local variable 'content' is assigned to but never used ./tests/app/main/views/test_activity.py:104:5: F841 local variable 'notification' is assigned to but never used ./tests/app/main/views/test_activity.py:337:5: F841 local variable '_notifications_mock' is assigned to but never used ./tests/app/main/views/test_activity.py:373:13: E126 continuation line over-indented for hanging indent ./tests/app/main/views/test_activity.py:378:9: E121 continuation line under-indented for hanging indent ./tests/app/main/views/test_activity.py:404:13: E126 continuation line over-indented for hanging indent ./tests/app/main/views/test_activity.py:407:9: E121 continuation line under-indented for hanging indent ./tests/app/main/views/test_api_keys.py:354:5: F841 local variable 'response' is assigned to but never used ./tests/app/main/views/test_conversation.py:5:1: F401 'bs4.BeautifulSoup' imported but unused ./tests/app/main/views/test_conversation.py:198:5: F841 local variable 'mock_get_inbound_sms' is assigned to but never used ./tests/app/main/views/test_dashboard.py:53:5: F841 local variable 'mock_template_stats' is assigned to but never used ./tests/app/main/views/test_dashboard.py:72:5: F841 local variable 'mock_template_stats' is assigned to but never used ./tests/app/main/views/test_jobs.py:2:1: F401 'uuid' imported but unused ./tests/app/main/views/test_jobs.py:3:1: F401 'urllib.parse.urlparse' imported but unused ./tests/app/main/views/test_jobs.py:3:1: F401 'urllib.parse.quote' imported but unused ./tests/app/main/views/test_jobs.py:3:1: F401 'urllib.parse.parse_qs' imported but unused ./tests/app/main/views/test_jobs.py:9:1: F401 'app.main.views.jobs.get_status_filters' imported but unused ./tests/app/main/views/test_jobs.py:10:1: F401 'tests.notification_json' imported but unused ./tests/app/main/views/test_letters.py:6:1: F401 'tests.service_json' imported but unused ./tests/app/main/views/test_notifications.py:5:1: F401 'app.utils.REQUESTED_STATUSES' imported but unused ./tests/app/main/views/test_notifications.py:5:1: F401 'app.utils.DELIVERED_STATUSES' imported but unused ./tests/app/main/views/test_notifications.py:5:1: F401 'app.utils.SENDING_STATUSES' imported but unused ./tests/app/main/views/test_notifications.py:5:1: F401 'app.utils.FAILURE_STATUSES' imported but unused ./tests/app/main/views/test_platform_admin.py:242:13: E126 continuation line over-indented for hanging indent ./tests/app/main/views/test_platform_admin.py:247:13: E126 continuation line over-indented for hanging indent ./tests/app/main/views/test_send.py:3:1: F401 'unittest.mock.Mock' imported but unused ./tests/app/main/views/test_send.py:18:1: F811 redefinition of unused 'mock_get_service' from line 18 ./tests/app/main/views/test_send.py:18:1: F401 'tests.conftest.multiple_letter_contact_blocks' imported but unused ./tests/app/main/views/test_send.py:18:1: F401 'tests.conftest.no_sms_senders' imported but unused ./tests/app/main/views/test_send.py:18:1: F401 'tests.conftest.multiple_sms_senders' imported but unused ./tests/app/main/views/test_send.py:18:1: F401 'tests.conftest.no_letter_contact_blocks' imported but unused ./tests/app/main/views/test_send.py:102:5: F841 local variable 'response' is assigned to but never used ./tests/app/main/views/test_send.py:870:5: F841 local variable 'response' is assigned to but never used ./tests/app/main/views/test_send.py:1367:5: F841 local variable 'service_id' is assigned to but never used ./tests/app/main/views/test_send.py:1451:13: E126 continuation line over-indented for hanging indent ./tests/app/main/views/test_send.py:1620:80: E226 missing whitespace around arithmetic operator ./tests/app/main/views/test_send.py:1909:13: E126 continuation line over-indented for hanging indent ./tests/app/main/views/test_send.py:1912:9: E121 continuation line under-indented for hanging indent ./tests/app/main/views/test_service_settings.py:13:1: F811 redefinition of unused 'no_reply_to_email_addresses' from line 13 ./tests/app/main/views/test_service_settings.py:13:1: F401 'tests.conftest.single_reply_to_email_address' imported but unused ./tests/app/main/views/test_service_settings.py:28:5: E123 closing bracket does not match indentation of opening bracket's line ./tests/app/main/views/test_service_settings.py:104:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:166:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:186:5: F841 local variable 'mocked_get_fn' is assigned to but never used ./tests/app/main/views/test_service_settings.py:217:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:237:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:257:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:307:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:340:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:466:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:555:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:615:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:719:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:874:5: F841 local variable 'page' is assigned to but never used ./tests/app/main/views/test_service_settings.py:902:5: F841 local variable 'page' is assigned to but never used ./tests/app/main/views/test_service_settings.py:954:5: F841 local variable 'page' is assigned to but never used ./tests/app/main/views/test_service_settings.py:986:5: F841 local variable 'page' is assigned to but never used ./tests/app/main/views/test_service_settings.py:1101:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:1121:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:1271:1: F811 redefinition of unused 'test_set_letter_contact_block_saves' from line 1189 ./tests/app/main/views/test_service_settings.py:1433:5: F841 local variable 'page' is assigned to but never used ./tests/app/main/views/test_service_settings.py:1495:5: F841 local variable 'mocked_get_fn' is assigned to but never used ./tests/app/main/views/test_service_settings.py:1540:5: F841 local variable 'mocked_get_fn' is assigned to but never used ./tests/app/main/views/test_service_settings.py:1570:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:1589:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:1621:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:1641:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:1658:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:1676:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:1697:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:1759:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_service_settings.py:1775:1: F811 redefinition of unused 'single_reply_to_email_address' from line 13 ./tests/app/main/views/test_templates.py:3:1: F401 'uuid' imported but unused ./tests/app/main/views/test_templates.py:11:1: F401 'tests.conftest.mock_get_user' imported but unused ./tests/app/main/views/test_templates.py:514:1: F811 redefinition of unused 'mock_get_user' from line 11 ./tests/app/main/views/test_templates.py:672:1: F811 redefinition of unused 'mock_get_user' from line 11 ./tests/app/main/views/test_templates.py:795:1: F811 redefinition of unused 'mock_get_user' from line 11 ./tests/app/main/views/test_templates.py:835:1: F811 redefinition of unused 'mock_get_user' from line 11 ./tests/app/main/views/test_two_factor.py:67:13: E126 continuation line over-indented for hanging indent ./tests/app/notify_client/test_notification_client.py:79:5: F841 local variable 'mock_post' is assigned to but never used ``` 1. https://gds-way.cloudapps.digital/manuals/programming-languages/python/linting.html#how-to-use-flake8 2. https://github.com/alphagov/digitalmarketplace-api/blob/d5ab8afef4a0472f9d266d94ab4ffe1333a9aaad/.flake8
2017-10-18 14:51:26 +01:00
'phone_numbers': list(filter(None, form.phone_numbers.data))
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
})
Rename ‘whitelist’ to ‘guest list’ in UI This commit changes all the places where a user would see the term ‘whitelist’ in the content of page to say guestlist instead. We’re removing the term ‘whitelist’ for two reasons. The first reason is that we agree with the National Cyber Security Centre say: > It's fairly common to say whitelisting and blacklisting to describe > desirable and undesirable things in cyber security. For instance, when > talking about which applications you will allow or deny on your > corporate network; or deciding which bad passwords you want your users > not to be able to use. > However, there's an issue with the terminology. It only makes sense if > you equate white with 'good, permitted, safe' and black with 'bad, > dangerous, forbidden'. There are some obvious problems with this. So > in the name of helping to stamp out racism in cyber security, we will > avoid this casually pejorative wording on our website in the future. > No, it's not the biggest issue in the world - but to borrow a slogan > from elsewhere: every little helps. – https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white The second reason is that we’ve observed some users think that they have to put recipients in the whitelist even when they’re already with in the team. We think that the term ‘whitelist’ might be reinforcing this mental model because of how ‘whitelists’ might work in other applications. We considered the following alternatives or concepts: - Development - Recipients - Sandbox - Extended team - Smoke test recipients - Allowed - Nominated - Bonus - Additional - Safe - Team list - Trusted contacts - Designated people - Guest list - Team key list We also considered not giving it a name, and explaining it as a nuance of how the team key works. After mocking this up it felt more disjoined. We think it’s still useful for the thing to have a name so that it’s easy to refer to between the docs and the UI. We like the term ‘guest list’ because: - of how it sits with team members – members and guests in the abstract - a guest list is a concept that a lot of people will be familiar with – a list of people who can access a thing - ‘guest’ is very different to ‘recipient’ – we want to mitigate any confusion between this and the (emergency) contact lists
2020-06-12 09:00:08 +01:00
flash('Guest list updated', 'default_with_tick')
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
return redirect(url_for('.api_integration', service_id=service_id))
if not form.errors:
Rename API client methods to remove term ‘whitelist’ See c31264d4c for rationale. To avoid confusion the codebase should use the same terminology as the UI.
2020-06-12 09:05:26 +01:00
form.populate(**service_api_client.get_guest_list(service_id))
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
return render_template(
Rename Jinja template to remove term ‘whitelist’ See c31264d4c for rationale. To avoid confusion the codebase should use the same terminology as the UI.
2020-06-12 09:06:22 +01:00
'views/api/guest-list.html',
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
form=form
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/api/keys")
remove admin_override from all has_permissions usage as previously pointed out, it's not used anywhere.
2018-03-01 10:30:17 +00:00
@user_has_permissions('manage_api_keys')
Move view function into own file, add test
2016-01-16 10:59:16 +00:00
def api_keys(service_id):
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
return render_template(
Reorganise templates for API keys page This adds another layer of folder structure to the templates to match the new URLs, which have another layer of hierarchy.
2016-09-20 11:23:59 +01:00
'views/api/keys.html',
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/api/keys/create", methods=['GET', 'POST'])
add restrict_admin_usage arg to admin_override rather than allow admins to do everything specifically, we should only block them from things we conciously don't want them to do. This is "Don't let platform admins send letters from services they're not in". Everything else the platform admins can do. This is step one, adding a restrict_admin_usage flag, and setting that for those restricted endpoints around creating api keys, uploading CSVs and sending one-off messages. Also, this commit separates the two use cases for permissions: * user.has_permission for access control * user.has_permission_for_service for user info - this is used for showing checkboxes on the manage-users page for example With this, we can remove the admin_override flag from the permission decorator.
2018-02-28 18:13:29 +00:00
@user_has_permissions('manage_api_keys', restrict_admin_usage=True)
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
def create_api_key(service_id):
Move data transformation into the form Follows what we’re doing with the folders stuff. Avoids having too many very straightforward methods on the model. Especially when the data they need is only used by the form. So it’s better to encapsulate the logic in the form.
2018-11-13 09:57:17 +00:00
form = CreateKeyForm(current_service.api_keys)
Always show live key, reword key labels This is trying to resolve these confusions: - that you’re in trial mode, which means you can’t have a live key yet ( or you can but it wont work, which is what we used to have) - what does simulate mean The create key page is the right place to resolve these confusions because it’s where users are actively reading. This commit also removes the trial mode banner from API integration page because this where users _aren’t_ actively reading. A whole bunch of users weren’t seeing this banner at all. The implementation of the disabled API key options is kinda clunky because WTForms doesn’t have a native way of doing this. ¯\_(ツ)_/¯
2016-11-01 15:34:04 +00:00
form.key_type.choices = [
Updated the labels for API key creation options
2017-02-02 12:44:12 +00:00
(KEY_TYPE_NORMAL, 'Live – sends to anyone'),
Rename ‘whitelist’ to ‘guest list’ in UI This commit changes all the places where a user would see the term ‘whitelist’ in the content of page to say guestlist instead. We’re removing the term ‘whitelist’ for two reasons. The first reason is that we agree with the National Cyber Security Centre say: > It's fairly common to say whitelisting and blacklisting to describe > desirable and undesirable things in cyber security. For instance, when > talking about which applications you will allow or deny on your > corporate network; or deciding which bad passwords you want your users > not to be able to use. > However, there's an issue with the terminology. It only makes sense if > you equate white with 'good, permitted, safe' and black with 'bad, > dangerous, forbidden'. There are some obvious problems with this. So > in the name of helping to stamp out racism in cyber security, we will > avoid this casually pejorative wording on our website in the future. > No, it's not the biggest issue in the world - but to borrow a slogan > from elsewhere: every little helps. – https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white The second reason is that we’ve observed some users think that they have to put recipients in the whitelist even when they’re already with in the team. We think that the term ‘whitelist’ might be reinforcing this mental model because of how ‘whitelists’ might work in other applications. We considered the following alternatives or concepts: - Development - Recipients - Sandbox - Extended team - Smoke test recipients - Allowed - Nominated - Bonus - Additional - Safe - Team list - Trusted contacts - Designated people - Guest list - Team key list We also considered not giving it a name, and explaining it as a nuance of how the team key works. After mocking this up it felt more disjoined. We think it’s still useful for the thing to have a name so that it’s easy to refer to between the docs and the UI. We like the term ‘guest list’ because: - of how it sits with team members – members and guests in the abstract - a guest list is a concept that a lot of people will be familiar with – a list of people who can access a thing - ‘guest’ is very different to ‘recipient’ – we want to mitigate any confusion between this and the (emergency) contact lists
2020-06-12 09:00:08 +01:00
(KEY_TYPE_TEAM, 'Team and guest list – limits who you can send to'),
Updated the labels for API key creation options
2017-02-02 12:44:12 +00:00
(KEY_TYPE_TEST, 'Test – pretends to send messages'),
Always show live key, reword key labels This is trying to resolve these confusions: - that you’re in trial mode, which means you can’t have a live key yet ( or you can but it wont work, which is what we used to have) - what does simulate mean The create key page is the right place to resolve these confusions because it’s where users are actively reading. This commit also removes the trial mode banner from API integration page because this where users _aren’t_ actively reading. A whole bunch of users weren’t seeing this banner at all. The implementation of the disabled API key options is kinda clunky because WTForms doesn’t have a native way of doing this. ¯\_(ツ)_/¯
2016-11-01 15:34:04 +00:00
]
Convert create API key radios to GOVUK Frontend
2021-01-12 15:04:54 +00:00
# preserve order of items extended by starting with empty dicts
form.key_type.param_extensions = {'items': [{}, {}]}
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
if current_service.trial_mode:
Convert create API key radios to GOVUK Frontend
2021-01-12 15:04:54 +00:00
form.key_type.param_extensions['items'][0] = {
'disabled': True,
'hint': {
'html': Markup(
'Not available because your service is in '
'<a class="govuk-link govuk-link--no-visited-state" href="/features/trial-mode">trial mode</a>')
}
}
Make a service model and use for permissions Having the service floating about as JSON is a bit flakey. Could easily introduce a mistake where you mistype the name of a key and silently get `None`. Also means doing awkward things like `if 'permission' in current_service['permissions']`, whereas for users we can do the much cleaner `user.has_permission()`. So this commit: - introduces a model - adds a `.has_permission` method similar to the one we have for users
2018-07-20 08:43:02 +01:00
if current_service.has_permission('letter'):
Convert create API key radios to GOVUK Frontend
2021-01-12 15:04:54 +00:00
form.key_type.param_extensions['items'][1]['hint'] = {'text': 'Cannot be used to send letters'}
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
if form.validate_on_submit():
Convert create API key radios to GOVUK Frontend
2021-01-12 15:04:54 +00:00
if current_service.trial_mode and form.key_type.data == KEY_TYPE_NORMAL:
Always show live key, reword key labels This is trying to resolve these confusions: - that you’re in trial mode, which means you can’t have a live key yet ( or you can but it wont work, which is what we used to have) - what does simulate mean The create key page is the right place to resolve these confusions because it’s where users are actively reading. This commit also removes the trial mode banner from API integration page because this where users _aren’t_ actively reading. A whole bunch of users weren’t seeing this banner at all. The implementation of the disabled API key options is kinda clunky because WTForms doesn’t have a native way of doing this. ¯\_(ツ)_/¯
2016-11-01 15:34:04 +00:00
abort(400)
Save api_key.key_type from radio buttons
2016-07-06 15:10:36 +01:00
secret = api_key_api_client.create_api_key(
service_id=service_id,
key_name=form.key_name.data,
key_type=form.key_type.data
)
Make API key combination of secret and service ID In research we’ve seen people mix up the service ID and API key because they’re both 36 character UUIDs. We can’t get rid of the service ID because it’s used to look up the API key. Instead, we should change API key to be one long string, which contains both the service ID, API key and (optionally) the name of the key. For example: ``` casework_production-8b3aa916-ec82-434e-b0c5-d5d9b371d6a3-dcdc5083-2fee-4fba-8afd-51f3f4bcb7b0 ``` We still need to keep the old, separate, key and service ID for a while until people have updated their clients. But they’re now both on this page, rather than on two separate pages, which should make for less fussing anyway. This shouldn’t be rolled out until the new clients are available. - [ ] https://github.com/alphagov/notifications-python-client/pull/36 - [ ] https://github.com/alphagov/notifications-node-client/pull/10 - [ ] https://github.com/alphagov/notifications-ruby-client/pull/15 - [ ] https://github.com/alphagov/notifications-java-client/pull/38 - [ ] PHP????
2016-10-07 10:59:32 +01:00
return render_template(
'views/api/keys/show.html',
secret=secret,
service_id=service_id,
key_name=email_safe(form.key_name.data, whitespace='_')
)
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
return render_template(
Reorganise templates for API keys page This adds another layer of folder structure to the templates to match the new URLs, which have another layer of hierarchy.
2016-09-20 11:23:59 +01:00
'views/api/keys/create.html',
Convert create API key radios to GOVUK Frontend
2021-01-12 15:04:54 +00:00
form=form
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/api/keys/revoke/<uuid:key_id>", methods=['GET', 'POST'])
remove admin_override from all has_permissions usage as previously pointed out, it's not used anywhere.
2018-03-01 10:30:17 +00:00
@user_has_permissions('manage_api_keys')
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
def revoke_api_key(service_id, key_id):
Don’t do multiple get API calls when revoking It’s redundant to make two API calls here, one to get all keys and one to get a single key. Since the API calls are sequential we can speed things up by getting the one key from the list of all keys.
2018-11-07 11:53:29 +00:00
key_name = current_service.get_api_key(key_id)['name']
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
if request.method == 'GET':
Make deletion confirmation banner messages consistent across our app Also introduce a way to provide context to a banner / flash message that will be displayed in plain font style.
2018-11-15 17:14:03 +00:00
flash([
Update content following review
2018-11-16 11:03:16 +00:00
"Are you sure you want to revoke ‘{}’?".format(key_name),
"You will not be able to use this API key to connect to GOV.UK Notify."
], 'revoke this API key')
Implementation of api key pages. Revoke page will show the correct key name Show api keys shows a well formatted expiry date Fix tests for api key endpoints.
2016-01-21 12:28:05 +00:00
return render_template(
Use confirmation banner for revoking API keys Currently revoking an API key takes you to a separate page. It should work the same way as other destructive actions, ie staying on the same page but with a banner asking you to confirm the action.
2017-07-24 15:36:38 +01:00
'views/api/keys.html',
Implementation of api key pages. Revoke page will show the correct key name Show api keys shows a well formatted expiry date Fix tests for api key endpoints.
2016-01-21 12:28:05 +00:00
)
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
elif request.method == 'POST':
Created api_key_api_client. Implementation of create, revoke and show api keys for service. These calls work, however we still need to fix the tests.
2016-01-20 17:32:55 +00:00
api_key_api_client.revoke_api_key(service_id=service_id, key_id=key_id)
Use banners appropriately We’ve fiddled around with the banners quite a lot in the last few days. This commit reviews some of the older examples and makes sure that they’re: a) not broken b) using the most appropriate banner for the context
2016-02-05 10:33:14 +00:00
flash('‘{}’ was revoked'.format(key_name), 'default_with_tick')
Add pages for create/view/revoke API keys Copying what they’ve done on GOV.UK Pay, we should let users: - generate as many keys as they want - only see the key at time of creation - give keys a name - revoke any key at any time (this should be a one way operation) And based on discussions with @minglis and @servingUpAces, the keys should be used in conjunction with some kind of service ID, which gets encrypted with the key. In other words the secret itself never gets sent over the wire. This commit adds the UI (but not the underlying API integration) for doing the above.
2016-01-19 09:55:13 +00:00
return redirect(url_for('.api_keys', service_id=service_id))
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
def get_apis():
callback_api = None
inbound_api = None
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
if current_service.service_callback_api:
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
callback_api = service_api_client.get_service_callback_api(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.id,
Don’t allow use of `.get()` on service model Making people use a property is a sure way to make sure they’re spelling the name of the property correctly, and allows us to easily swap out properties that call through to the underlying JSON, and properties which are implemented as methods. The API should always return something in the JSON for a property, even if it’s just `None`.
2018-10-27 13:09:03 +01:00
current_service.service_callback_api[0]
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
)
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
if current_service.inbound_api:
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
inbound_api = service_api_client.get_service_inbound_api(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.id,
Don’t allow use of `.get()` on service model Making people use a property is a sure way to make sure they’re spelling the name of the property correctly, and allows us to easily swap out properties that call through to the underlying JSON, and properties which are implemented as methods. The API should always return something in the JSON for a property, even if it’s just `None`.
2018-10-27 13:09:03 +01:00
current_service.inbound_api[0]
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
)
return (callback_api, inbound_api)
def check_token_against_dummy_bearer(token):
if token != dummy_bearer_token:
return token
else:
return ''
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/api/callbacks", methods=['GET'])
Fix a bug were the user_has_permission. This is an immediate fix to add the permission checks to the callback page. However, we have a plan to add a unit test to check for permission introspectively for all routes that have service_id.
2019-06-27 12:20:58 +01:00
@user_has_permissions('manage_api_keys')
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
def api_callbacks(service_id):
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
if not current_service.has_permission('inbound_sms'):
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
return redirect(url_for('.delivery_status_callback', service_id=service_id))
Fix order of callbacks Delivery comes before inbound. The order of the URLs was jumbled in two places: - in the view function - in the Jinja template So as the user saw it the URLs were in the right order, because the double jumbling cancelled itself out. But it made the code _really_ confusing to read.
2017-12-13 11:42:41 +00:00
delivery_status_callback, received_text_messages_callback = get_apis()
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
return render_template(
'views/api/callbacks.html',
Merge branch 'master' of https://github.com/alphagov/notifications-admin into vb-callback-admin Some content change Refractor api_integration to api_keys to reduce git difference.
2017-12-11 12:03:23 +00:00
received_text_messages_callback=received_text_messages_callback['url']
if received_text_messages_callback else None,
fixed empty callback dict problem
2017-12-11 11:40:07 +00:00
delivery_status_callback=delivery_status_callback['url'] if delivery_status_callback else None
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
)
def get_delivery_status_callback_details():
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
if current_service.service_callback_api:
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
return service_api_client.get_service_callback_api(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.id,
current_service.service_callback_api[0]
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/api/callbacks/delivery-status-callback", methods=['GET', 'POST'])
Fix a bug were the user_has_permission. This is an immediate fix to add the permission checks to the callback page. However, we have a plan to add a unit test to check for permission introspectively for all routes that have service_id.
2019-06-27 12:20:58 +01:00
@user_has_permissions('manage_api_keys')
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
def delivery_status_callback(service_id):
delivery_status_callback = get_delivery_status_callback_details()
back_link = (
Make a service model and use for permissions Having the service floating about as JSON is a bit flakey. Could easily introduce a mistake where you mistype the name of a key and silently get `None`. Also means doing awkward things like `if 'permission' in current_service['permissions']`, whereas for users we can do the much cleaner `user.has_permission()`. So this commit: - introduces a model - adds a `.has_permission` method similar to the one we have for users
2018-07-20 08:43:02 +01:00
'.api_callbacks' if current_service.has_permission('inbound_sms')
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
else '.api_integration'
)
Consolidate callback forms and convert them to gov uk frontend We had two identical callback form classes. One for delivery callbacks and one for inbound sms callbacks. Since they did not differ I consolidated them into one CallbackForm class that they both inherited from previously. I also substituted field classes for this form with new fields that cooperate with gov uk frontend.
2020-08-03 15:10:02 +01:00
form = CallbackForm(
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
url=delivery_status_callback.get('url') if delivery_status_callback else '',
bearer_token=dummy_bearer_token if delivery_status_callback else ''
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
)
if form.validate_on_submit():
Allow callbacks to be removed We’ve had a user who’s said: > Seems configured callbacks cannot be removed once they’re set as the > fields have a presence check. Is that intentional? This means it’s not working as they expect. Rather than have to go and change stuff in the database for them, let’s make it work as they’d expect. Only lets you clear the form if you remove both the token and the URL.
2018-04-26 17:23:44 +01:00
if delivery_status_callback and form.url.data:
if (
delivery_status_callback.get('url') != form.url.data or
form.bearer_token.data != dummy_bearer_token
):
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
service_api_client.update_service_callback_api(
service_id,
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
url=form.url.data,
bearer_token=check_token_against_dummy_bearer(form.bearer_token.data),
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
user_id=current_user.id,
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
callback_api_id=delivery_status_callback.get('id')
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
)
Allow callbacks to be removed We’ve had a user who’s said: > Seems configured callbacks cannot be removed once they’re set as the > fields have a presence check. Is that intentional? This means it’s not working as they expect. Rather than have to go and change stuff in the database for them, let’s make it work as they’d expect. Only lets you clear the form if you remove both the token and the URL.
2018-04-26 17:23:44 +01:00
elif delivery_status_callback and not form.url.data:
service_api_client.delete_service_callback_api(
service_id,
delivery_status_callback['id'],
)
elif form.url.data:
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
service_api_client.create_service_callback_api(
service_id,
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
url=form.url.data,
bearer_token=form.bearer_token.data,
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
user_id=current_user.id
)
Make expected behaviour clear in `else` case It feels a bit slippery having an `if`/`elif` with no else; I think that adding this comment makes the code clearer.
2018-06-18 12:52:12 +01:00
else:
# If no callback is set up and the user chooses to continue
# having no callback (ie both fields empty) then there’s
# nothing for us to do here
pass
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
return redirect(url_for(back_link, service_id=service_id))
return render_template(
'views/api/callbacks/delivery-status-callback.html',
back_link=back_link,
form=form,
)
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
def get_received_text_messages_callback():
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
if current_service.inbound_api:
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
return service_api_client.get_service_inbound_api(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.id,
Don’t allow use of `.get()` on service model Making people use a property is a sure way to make sure they’re spelling the name of the property correctly, and allows us to easily swap out properties that call through to the underlying JSON, and properties which are implemented as methods. The API should always return something in the JSON for a property, even if it’s just `None`.
2018-10-27 13:09:03 +01:00
current_service.inbound_api[0]
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/api/callbacks/received-text-messages-callback", methods=['GET', 'POST'])
Fix a bug were the user_has_permission. This is an immediate fix to add the permission checks to the callback page. However, we have a plan to add a unit test to check for permission introspectively for all routes that have service_id.
2019-06-27 12:20:58 +01:00
@user_has_permissions('manage_api_keys')
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
def received_text_messages_callback(service_id):
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
if not current_service.has_permission('inbound_sms'):
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
return redirect(url_for('.api_integration', service_id=service_id))
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
received_text_messages_callback = get_received_text_messages_callback()
Consolidate callback forms and convert them to gov uk frontend We had two identical callback form classes. One for delivery callbacks and one for inbound sms callbacks. Since they did not differ I consolidated them into one CallbackForm class that they both inherited from previously. I also substituted field classes for this form with new fields that cooperate with gov uk frontend.
2020-08-03 15:10:02 +01:00
form = CallbackForm(
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
url=received_text_messages_callback.get('url') if received_text_messages_callback else '',
bearer_token=dummy_bearer_token if received_text_messages_callback else ''
)
if form.validate_on_submit():
Allow callbacks to be removed We’ve had a user who’s said: > Seems configured callbacks cannot be removed once they’re set as the > fields have a presence check. Is that intentional? This means it’s not working as they expect. Rather than have to go and change stuff in the database for them, let’s make it work as they’d expect. Only lets you clear the form if you remove both the token and the URL.
2018-04-26 17:23:44 +01:00
if received_text_messages_callback and form.url.data:
if (
received_text_messages_callback.get('url') != form.url.data or
form.bearer_token.data != dummy_bearer_token
):
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
service_api_client.update_service_inbound_api(
service_id,
url=form.url.data,
bearer_token=check_token_against_dummy_bearer(form.bearer_token.data),
user_id=current_user.id,
inbound_api_id=received_text_messages_callback.get('id')
)
Allow callbacks to be removed We’ve had a user who’s said: > Seems configured callbacks cannot be removed once they’re set as the > fields have a presence check. Is that intentional? This means it’s not working as they expect. Rather than have to go and change stuff in the database for them, let’s make it work as they’d expect. Only lets you clear the form if you remove both the token and the URL.
2018-04-26 17:23:44 +01:00
elif received_text_messages_callback and not form.url.data:
service_api_client.delete_service_inbound_api(
service_id,
received_text_messages_callback['id'],
)
elif form.url.data:
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
service_api_client.create_service_inbound_api(
service_id,
url=form.url.data,
bearer_token=form.bearer_token.data,
user_id=current_user.id
)
return redirect(url_for('.api_callbacks', service_id=service_id))
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
return render_template(
refactor of api callbacks admin work
2017-12-08 10:52:38 +00:00
'views/api/callbacks/received-text-messages-callback.html',
Allow service to set callback url for notifications
2017-12-04 15:07:11 +00:00
form=form,
)
Reference in New Issue Copy Permalink