darkhelm/notifications-api
1
0
Fork 0
mirror of https://github.com/GSA/notifications-api.git synced 2025-12-23 08:51:30 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
4a90cde701e0e29e2dd9eae51bd3f1ce005d5ff4
notifications-api/app/v2/broadcast/broadcast_schemas.py

124 lines
2.9 KiB
Python
Raw Normal View History

Validate broadcast against schema This commit adds a JSONSchema which can validate the fields in an API call to create a broadcast. It takes the CAP XML schema as a starting point.
2021-01-18 10:01:44 +00:00
post_broadcast_schema = {
"$schema": "http://json-schema.org/draft-07/schema",
"type": "object",
"required": [
Don’t accept cancel or update via broadcast API We don’t support these methods at the moment. Instead we were just ignoring the `msgType` field, so issuing one of these commands would cause a new alert to be broadcast 🙃 We might want to support `Cancel` in the future, but for now let’s reject anything that isn’t `Alert` (CAP terminology for the initial broadcast).
2021-02-15 09:32:33 +00:00
"msgType",
Validate broadcast against schema This commit adds a JSONSchema which can validate the fields in an API call to create a broadcast. It takes the CAP XML schema as a starting point.
2021-01-18 10:01:44 +00:00
"reference",
Store the `event` field from CAP XML broadcasts We don’t store everything that comes in the CAP XML when someone creates a broadcast via the API. One thing we do store is `<identifier>` (in a column called `reference`) which is a unique (to the external system) identifier for the broadcast. We show this in the front end instead of the template name, because broadcasts created from the API don’t use templates. However this ID isn’t very friendly – the Environment Agency just supply a UUID. The Environment Agency also populate the `<event>` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an area code which will be meaningful to the Flood Warning Service team) We should show this in the UI instead of the reference. The first step towards this is storing it in the database and returning it in the REST endpoints. Later we can have the admin app prefer `cap_event` over `reference`, where `cap_event` is present. We can’t backfill this data because we don’t keep a copy of the original XML. Seems like `<event>` is a mandatory property of `<info>`, so we don’t need to worry about the field being missing (`<info>` is optional in CAP but we require it because it contains stuff like the areas which we need in order to send out the broadcast`). *** https://www.pivotaltracker.com/story/show/176927060
2021-10-18 11:42:18 +01:00
"cap_event",
Validate broadcast against schema This commit adds a JSONSchema which can validate the fields in an API call to create a broadcast. It takes the CAP XML schema as a starting point.
2021-01-18 10:01:44 +00:00
"category",
"content",
"areas",
],
"additionalProperties": False,
"properties": {
"reference": {
"type": [
"string",
"null",
],
},
Reject unapproved broadcast upon cancel API request When a service sends us a cancel broadcast XML via API, if that broadcast was not approved yet, reject it.
2022-01-19 15:41:38 +00:00
"references": {
"type": [
"string",
"null",
],
},
Store the `event` field from CAP XML broadcasts We don’t store everything that comes in the CAP XML when someone creates a broadcast via the API. One thing we do store is `<identifier>` (in a column called `reference`) which is a unique (to the external system) identifier for the broadcast. We show this in the front end instead of the template name, because broadcasts created from the API don’t use templates. However this ID isn’t very friendly – the Environment Agency just supply a UUID. The Environment Agency also populate the `<event>` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an area code which will be meaningful to the Flood Warning Service team) We should show this in the UI instead of the reference. The first step towards this is storing it in the database and returning it in the REST endpoints. Later we can have the admin app prefer `cap_event` over `reference`, where `cap_event` is present. We can’t backfill this data because we don’t keep a copy of the original XML. Seems like `<event>` is a mandatory property of `<info>`, so we don’t need to worry about the field being missing (`<info>` is optional in CAP but we require it because it contains stuff like the areas which we need in order to send out the broadcast`). *** https://www.pivotaltracker.com/story/show/176927060
2021-10-18 11:42:18 +01:00
"cap_event": {
"type": [
"string",
"null",
],
},
Validate broadcast against schema This commit adds a JSONSchema which can validate the fields in an API call to create a broadcast. It takes the CAP XML schema as a starting point.
2021-01-18 10:01:44 +00:00
"category": {
"type": "string",
"enum": [
"Geo",
"Met",
"Safety",
"Security",
"Rescue",
"Fire",
"Health",
"Env",
"Transport",
"Infra",
"CBRNE",
"Other",
],
},
"expires": {
"type": "string",
"format": "date-time",
},
"content": {
"type": "string",
"minLength": 1,
},
"web": {
"type": "string",
"format": "uri",
},
"areas": {
"type": "array",
"minItems": 1,
"items": {
"$ref": "#/definitions/area",
},
},
Don’t accept cancel or update via broadcast API We don’t support these methods at the moment. Instead we were just ignoring the `msgType` field, so issuing one of these commands would cause a new alert to be broadcast 🙃 We might want to support `Cancel` in the future, but for now let’s reject anything that isn’t `Alert` (CAP terminology for the initial broadcast).
2021-02-15 09:32:33 +00:00
"msgType": {
"type": "string",
"enum": [
"Alert",
Reject unapproved broadcast upon cancel API request When a service sends us a cancel broadcast XML via API, if that broadcast was not approved yet, reject it.
2022-01-19 15:41:38 +00:00
"Cancel",
Don’t accept cancel or update via broadcast API We don’t support these methods at the moment. Instead we were just ignoring the `msgType` field, so issuing one of these commands would cause a new alert to be broadcast 🙃 We might want to support `Cancel` in the future, but for now let’s reject anything that isn’t `Alert` (CAP terminology for the initial broadcast).
2021-02-15 09:32:33 +00:00
# The following are valid CAP but not supported by our
# API at the moment
# "Update",
# "Ack",
# "Error",
],
}
Validate broadcast against schema This commit adds a JSONSchema which can validate the fields in an API call to create a broadcast. It takes the CAP XML schema as a starting point.
2021-01-18 10:01:44 +00:00
},
"definitions": {
"area": {
"type": "object",
"required": [
"name",
"polygons",
],
"additionalProperties": False,
"properties": {
"name": {
"type": "string",
Add validation to prevent blank area names Now that these are used for display on gov.uk/alerts we need to make sure the data is being set properly. We've already found an example where it wasn't [1]. We validate external broadcasts in two stages: with the official CAP XML schema [2] and then again with our own, more specific schema for the converted JSON. Since this validation is a custom requirement I've made it part of the JSON schema. Note that jsonschema recommends avoiding metachars like "\w" since they're not supported by all implementations [3]. I've tested the new validation manually and it works as expected by disallowing e.g. " " but still alowing "foo" and "foo bar". [1]: https://www.notifications.service.gov.uk/services/120107d0-d99a-4c42-8b70-f37d2f28879b/rejected-alerts/d6e0c70e-60f6-4422-8589-2a2d159c63f2 [2]: https://github.com/alphagov/notifications-api/blob/81a25ff1effa821f0096fcc5edea79b0a5b17f5e/app/xml_schemas/CAP-v1.2.xsd [3]: http://json-schema.org/understanding-json-schema/reference/regular_expressions.html
2021-09-08 13:21:23 +01:00
"pattern": "([a-zA-Z1-9]+ )*[a-zA-Z1-9]+",
Validate broadcast against schema This commit adds a JSONSchema which can validate the fields in an API call to create a broadcast. It takes the CAP XML schema as a starting point.
2021-01-18 10:01:44 +00:00
},
"polygons": {
"type": "array",
"minItems": 1,
"items": {
"oneOf": [
{
"$ref": "#/definitions/polygon",
},
],
},
},
},
},
"polygon": {
"type": "array",
"minItems": 4,
"items": {
"$ref": "#/definitions/coordinatePair",
},
},
"coordinatePair": {
"type": "array",
"items": {
"type": "number"
},
"minItems": 2,
"maxItems": 2,
},
},
}
Reference in New Issue Copy Permalink