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
0b6f1d818bf3ad68e2e6d0de2d1f84a2ecac43de
notifications-api/tests/app/notifications/rest/test_callbacks.py

279 lines
12 KiB
Python
Raw Normal View History

We are not handling the case of an unknown status code sent by the SMS provider. This PR attempts to fix that. - If the SMS client sends a status code that we do not recognize raise a ClientException and set the notification status to technical-failure - Simplified the code in process_client_response, using a simple map.
2018-02-07 17:49:15 +00:00
import pytest
move callback tests into separate file also fix syntax errors
2016-07-05 12:37:27 +01:00
from flask import json
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
from app.notifications.notifications_sms_callback import validate_callback_data
move callback tests into separate file also fix syntax errors
2016-07-05 12:37:27 +01:00
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
def firetext_post(client, data):
return client.post(
path='/notifications/sms/firetext',
data=data,
headers=[
('Content-Type', 'application/x-www-form-urlencoded'),
fixed code style
2017-12-01 22:24:53 +00:00
('X-Forwarded-For', '203.0.113.195, 70.41.3.18, 150.172.238.178') # fake IPs
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
])
def mmg_post(client, data):
return client.post(
path='/notifications/sms/mmg',
data=data,
headers=[
('Content-Type', 'application/json'),
fixed code style
2017-12-01 22:24:53 +00:00
('X-Forwarded-For', '203.0.113.195, 70.41.3.18, 150.172.238.178') # fake IPs
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
])
def dvla_post(client, data):
return client.post(
Wired in a simple callback to handle SNS notifications from S3 S3 will send a message when a file lands - which will trigger processing of DVLA responses.
2017-04-25 14:56:16 +01:00
path='/notifications/letter/dvla',
data=data,
Add DVLA callback: * Process SNS callback, trigger the update notifications celery task * Put autoconfirm into its own method and use in callbacks
2017-05-15 11:12:31 +01:00
headers=[('Content-Type', 'application/json')]
)
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
def test_dvla_callback_returns_400_with_invalid_request(client):
data = json.dumps({"foo": "bar"})
response = dvla_post(client, data)
Add DVLA callback: * Process SNS callback, trigger the update notifications celery task * Put autoconfirm into its own method and use in callbacks
2017-05-15 11:12:31 +01:00
assert response.status_code == 400
def test_dvla_callback_autoconfirms_subscription(client, mocker):
autoconfirm_mock = mocker.patch('app.notifications.notifications_letter_callback.autoconfirm_subscription')
ensure sample SES callbacks and SNS subscription payloads are accurate in research mode and unit tests
2017-11-17 14:25:59 +00:00
data = _sns_confirmation_callback()
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
response = dvla_post(client, data)
Update DVLA callback to process request and call task (if it can)
2017-05-04 10:33:44 +01:00
assert response.status_code == 200
Add DVLA callback: * Process SNS callback, trigger the update notifications celery task * Put autoconfirm into its own method and use in callbacks
2017-05-15 11:12:31 +01:00
assert autoconfirm_mock.called
def test_dvla_callback_autoconfirm_does_not_call_update_letter_notifications_task(client, mocker):
autoconfirm_mock = mocker.patch('app.notifications.notifications_letter_callback.autoconfirm_subscription')
update_task = \
mocker.patch('app.notifications.notifications_letter_callback.update_letter_notifications_statuses.apply_async')
ensure sample SES callbacks and SNS subscription payloads are accurate in research mode and unit tests
2017-11-17 14:25:59 +00:00
data = _sns_confirmation_callback()
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
response = dvla_post(client, data)
Add DVLA callback: * Process SNS callback, trigger the update notifications celery task * Put autoconfirm into its own method and use in callbacks
2017-05-15 11:12:31 +01:00
assert response.status_code == 200
assert autoconfirm_mock.called
assert not update_task.called
Update callback handling to process DVLA response files - handle `RS.TXT` and `RSP.TXT` files
2018-01-15 14:09:46 +00:00
def test_dvla_callback_calls_does_not_update_letter_notifications_task_with_invalid_file_type(client, mocker):
Add DVLA callback: * Process SNS callback, trigger the update notifications celery task * Put autoconfirm into its own method and use in callbacks
2017-05-15 11:12:31 +01:00
update_task = \
mocker.patch('app.notifications.notifications_letter_callback.update_letter_notifications_statuses.apply_async')
Update callback handling to process DVLA response files - handle `RS.TXT` and `RSP.TXT` files
2018-01-15 14:09:46 +00:00
data = _sample_sns_s3_callback("bar.txt")
response = dvla_post(client, data)
assert response.status_code == 200
assert not update_task.called
Split the update letter statuses from counting the daily sorted/unsorted numbers. We need to back fill the daily_sorted_count tables, so we need to iterate through all the files. No need to update the notification status. So this task has been separated out.
2019-03-25 15:30:48 +00:00
@pytest.mark.parametrize("filename",
['Notify-20170411153023-rs.txt', 'Notify-20170411153023-rsp.txt'])
def test_dvla_rs_and_rsp_txt_file_callback_calls_update_letter_notifications_task(client, mocker, filename):
update_task = mocker.patch(
'app.notifications.notifications_letter_callback.update_letter_notifications_statuses.apply_async')
daily_sorted_counts_task = mocker.patch(
'app.notifications.notifications_letter_callback.record_daily_sorted_counts.apply_async')
data = _sample_sns_s3_callback(filename)
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
response = dvla_post(client, data)
Add DVLA callback: * Process SNS callback, trigger the update notifications celery task * Put autoconfirm into its own method and use in callbacks
2017-05-15 11:12:31 +01:00
assert response.status_code == 200
assert update_task.called
Split the update letter statuses from counting the daily sorted/unsorted numbers. We need to back fill the daily_sorted_count tables, so we need to iterate through all the files. No need to update the notification status. So this task has been separated out.
2019-03-25 15:30:48 +00:00
update_task.assert_called_with([filename], queue='notify-internal-tasks')
daily_sorted_counts_task.assert_called_with([filename], queue='notify-internal-tasks')
Update DVLA callback to process request and call task (if it can)
2017-05-04 10:33:44 +01:00
Add tests for checking not updating database when ack file is received. Moved S3 test scripts Modified scheduled_task test
2018-01-12 19:24:36 +00:00
def test_dvla_ack_calls_does_not_call_letter_notifications_task(client, mocker):
Split the update letter statuses from counting the daily sorted/unsorted numbers. We need to back fill the daily_sorted_count tables, so we need to iterate through all the files. No need to update the notification status. So this task has been separated out.
2019-03-25 15:30:48 +00:00
update_task = mocker.patch(
'app.notifications.notifications_letter_callback.update_letter_notifications_statuses.apply_async')
daily_sorted_counts_task = mocker.patch(
'app.notifications.notifications_letter_callback.record_daily_sorted_counts.apply_async')
Update callback handling to process DVLA response files - handle `RS.TXT` and `RSP.TXT` files
2018-01-15 14:09:46 +00:00
data = _sample_sns_s3_callback('bar.ack.txt')
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
response = dvla_post(client, data)
Force parse JSON received from SNS: * An SNS callback containing JSON has a plaintext header set. Using * request.get_json() will return None if the header is not * application/json unless the force parameter is set to True
2017-05-16 10:29:27 +01:00
assert response.status_code == 200
Add tests for checking not updating database when ack file is received. Moved S3 test scripts Modified scheduled_task test
2018-01-12 19:24:36 +00:00
update_task.assert_not_called()
Split the update letter statuses from counting the daily sorted/unsorted numbers. We need to back fill the daily_sorted_count tables, so we need to iterate through all the files. No need to update the notification status. So this task has been separated out.
2019-03-25 15:30:48 +00:00
daily_sorted_counts_task.assert_not_called()
Force parse JSON received from SNS: * An SNS callback containing JSON has a plaintext header set. Using * request.get_json() will return None if the header is not * application/json unless the force parameter is set to True
2017-05-16 10:29:27 +01:00
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
def test_firetext_callback_should_not_need_auth(client, mocker):
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
mocker.patch('app.notifications.notifications_sms_callback.process_sms_client_response')
data = 'mobile=441234123123&status=0&reference=notification_id&time=2016-03-10 14:17:00'
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
response = firetext_post(client, data)
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
assert response.status_code == 200
def test_firetext_callback_should_return_400_if_empty_reference(client, mocker):
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
data = 'mobile=441234123123&status=0&reference=&time=2016-03-10 14:17:00'
response = firetext_post(client, data)
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
json_resp = json.loads(response.get_data(as_text=True))
assert response.status_code == 400
assert json_resp['result'] == 'error'
assert json_resp['message'] == ['Firetext callback failed: reference missing']
def test_firetext_callback_should_return_400_if_no_reference(client, mocker):
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
data = 'mobile=441234123123&status=0&time=2016-03-10 14:17:00'
response = firetext_post(client, data)
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
json_resp = json.loads(response.get_data(as_text=True))
assert response.status_code == 400
assert json_resp['result'] == 'error'
assert json_resp['message'] == ['Firetext callback failed: reference missing']
def test_firetext_callback_should_return_400_if_no_status(client, mocker):
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
data = 'mobile=441234123123&time=2016-03-10 14:17:00&reference=notification_id'
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
response = firetext_post(client, data)
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
json_resp = json.loads(response.get_data(as_text=True))
assert response.status_code == 400
assert json_resp['result'] == 'error'
assert json_resp['message'] == ['Firetext callback failed: status missing']
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
def test_firetext_callback_should_return_200_and_call_task_with_valid_data(client, mocker):
mock_celery = mocker.patch(
'app.notifications.notifications_sms_callback.process_sms_client_response.apply_async')
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
data = 'mobile=441234123123&status=0&time=2016-03-10 14:17:00&reference=notification_id'
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
response = firetext_post(client, data)
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
json_resp = json.loads(response.get_data(as_text=True))
assert response.status_code == 200
assert json_resp['result'] == 'success'
move callback tests into separate file also fix syntax errors
2016-07-05 12:37:27 +01:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
mock_celery.assert_called_once_with(
Use firetext response code to see if temporary or permanent failure if available
2020-04-14 15:55:17 +01:00
['0', 'notification_id', 'Firetext', None],
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
queue='sms-callbacks',
added sms delivery status callback
2017-12-01 20:30:53 +00:00
)
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Add test for a callback with a code
2020-04-16 13:14:29 +01:00
def test_firetext_callback_including_a_code_should_return_200_and_call_task_with_valid_data(client, mocker):
mock_celery = mocker.patch(
'app.notifications.notifications_sms_callback.process_sms_client_response.apply_async')
data = 'mobile=441234123123&status=1&code=101&time=2016-03-10 14:17:00&reference=notification_id'
response = firetext_post(client, data)
json_resp = json.loads(response.get_data(as_text=True))
assert response.status_code == 200
assert json_resp['result'] == 'success'
mock_celery.assert_called_once_with(
['1', 'notification_id', 'Firetext', '101'],
queue='sms-callbacks',
)
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
def test_mmg_callback_should_not_need_auth(client, mocker, sample_notification):
mocker.patch('app.notifications.notifications_sms_callback.process_sms_client_response')
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
data = json.dumps({"reference": "mmg_reference",
Stop calling fixures as functions in the tests
2019-10-31 15:02:30 +00:00
"CID": str(sample_notification.id),
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
"MSISDN": "447777349060",
"status": "3",
"deliverytime": "2016-04-05 16:01:07"})
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
response = mmg_post(client, data)
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
assert response.status_code == 200
def test_process_mmg_response_returns_400_for_malformed_data(client):
data = json.dumps({"reference": "mmg_reference",
"monkey": 'random thing',
"MSISDN": "447777349060",
"no_status": 00,
"deliverytime": "2016-04-05 16:01:07"})
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
response = mmg_post(client, data)
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
assert response.status_code == 400
json_data = json.loads(response.data)
assert json_data['result'] == 'error'
assert len(json_data['message']) == 2
assert "{} callback failed: {} missing".format('MMG', 'status') in json_data['message']
assert "{} callback failed: {} missing".format('MMG', 'CID') in json_data['message']
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
def test_mmg_callback_should_return_200_and_call_task_with_valid_data(client, mocker):
mock_celery = mocker.patch(
'app.notifications.notifications_sms_callback.process_sms_client_response.apply_async')
data = json.dumps({"reference": "mmg_reference",
"CID": "notification_id",
"MSISDN": "447777349060",
"status": "3",
Log detailed sms delivery status for mmg from process_sms_client_response task. Also log detailed delivery status for firetext in the same place in addition to it being logged from notifications_dao. Logging detailed delivery statuses will help us see why messages fail to deliver. In the future we could persist detailed delivery status in the database.
2020-05-27 18:03:55 +01:00
"substatus": "5",
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
"deliverytime": "2016-04-05 16:01:07"})
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Enable Inbound sms IP blocking
2017-09-26 10:59:09 +01:00
response = mmg_post(client, data)
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
assert response.status_code == 200
json_data = json.loads(response.data)
assert json_data['result'] == 'success'
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
mock_celery.assert_called_once_with(
Log detailed sms delivery status for mmg from process_sms_client_response task. Also log detailed delivery status for firetext in the same place in addition to it being logged from notifications_dao. Logging detailed delivery statuses will help us see why messages fail to deliver. In the future we could persist detailed delivery status in the database.
2020-05-27 18:03:55 +01:00
['3', 'notification_id', 'MMG', '5'],
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
queue='sms-callbacks',
)
Make the errors in the process_sms_client_reponse more obvious by changing variable name. Added a missing test if mmg sends a CID (or reference) that is not a UUID. NB: All client specific tests are in test_callbacks.
2018-02-12 12:06:43 +00:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
def test_validate_callback_data_returns_none_when_valid():
form = {'status': 'good',
'reference': 'send-sms-code'}
fields = ['status', 'reference']
client_name = 'sms client'
Make the errors in the process_sms_client_reponse more obvious by changing variable name. Added a missing test if mmg sends a CID (or reference) that is not a UUID. NB: All client specific tests are in test_callbacks.
2018-02-12 12:06:43 +00:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
assert validate_callback_data(form, fields, client_name) is None
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
def test_validate_callback_data_return_errors_when_fields_are_empty():
form = {'monkey': 'good'}
fields = ['status', 'cid']
client_name = 'sms client'
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
errors = validate_callback_data(form, fields, client_name)
assert len(errors) == 2
assert "{} callback failed: {} missing".format(client_name, 'status') in errors
assert "{} callback failed: {} missing".format(client_name, 'cid') in errors
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
def test_validate_callback_data_can_handle_integers():
form = {'status': 00, 'cid': 'fsdfadfsdfas'}
fields = ['status', 'cid']
client_name = 'sms client'
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
result = validate_callback_data(form, fields, client_name)
assert result is None
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
def test_validate_callback_data_returns_error_for_empty_string():
form = {'status': '', 'cid': 'fsdfadfsdfas'}
fields = ['status', 'cid']
client_name = 'sms client'
Return success of the callback is a duplicate or for an id that does not exist This PR changes the response to POST /notifications/sms/<mmg | firetext> from a 400 response to a 200 response. If we get a callback for a notification more than once or for a notification we log that but we return a 200 success response to the provider. We have found that there is a situation where the send to provider throws a timeout exception but the provider did get the message, but we still send it to them again. In which case they send the message twice, and callback for the message twice. Another case where we may get duplicate callbacks is that the network gave the provider two callbacks meaning they pass those two callbacks onto us. So it is really difficult to know if we sent to the provider twice or just got two callbacks. The test_callback has many changes because I took the opportunity to use the client conftest fixture rather than the notify_api fixture. The only 2 tests really changed are test_mmg_callback_returns_200_when_notification_id_not_found_or_already_updated and test_firetext_callback_returns_200_when_notification_id_not_found_or_already_updated
2017-01-25 14:37:11 +00:00
Add a task to process sms callback from our providers This runs on the new `sms-callbacks` queue. The function `process_sms_client_response` has been replaced with a task called `process_sms_client_response`. This involved some reorganisation of the existing code and tests.
2020-03-17 15:15:43 +00:00
result = validate_callback_data(form, fields, client_name)
assert result is not None
assert "{} callback failed: {} missing".format(client_name, 'status') in result
move callback tests into separate file also fix syntax errors
2016-07-05 12:37:27 +01:00
Update callback handling to process DVLA response files - handle `RS.TXT` and `RSP.TXT` files
2018-01-15 14:09:46 +00:00
def _sample_sns_s3_callback(filename):
message_contents = '''{"Records":[{"eventVersion":"2.0","eventSource":"aws:s3","awsRegion":"eu-west-1","eventTime":"2017-05-16T11:38:41.073Z","eventName":"ObjectCreated:Put","userIdentity":{"principalId":"some-p-id"},"requestParameters":{"sourceIPAddress":"8.8.8.8"},"responseElements":{"x-amz-request-id":"some-r-id","x-amz-id-2":"some-x-am-id"},"s3":{"s3SchemaVersion":"1.0","configurationId":"some-c-id","bucket":{"name":"some-bucket","ownerIdentity":{"principalId":"some-p-id"},"arn":"some-bucket-arn"},
"object":{"key":"%s"}}}]}''' % (filename) # noqa
Added a new sns callback for testing old dvla response file type. Merge branch 'raise-alert-when-no-ack-file' of https://github.com/alphagov/notifications-api into raise-alert-when-no-ack-file
2018-01-12 16:10:09 +00:00
return json.dumps({
"SigningCertURL": "foo.pem",
"UnsubscribeURL": "bar",
"Signature": "some-signature",
"Type": "Notification",
"Timestamp": "2016-05-03T08:35:12.884Z",
"SignatureVersion": "1",
"MessageId": "6adbfe0a-d610-509a-9c47-af894e90d32d",
"Subject": "Amazon S3 Notification",
"TopicArn": "sample-topic-arn",
Update callback handling to process DVLA response files - handle `RS.TXT` and `RSP.TXT` files
2018-01-15 14:09:46 +00:00
"Message": message_contents
Added a new sns callback for testing old dvla response file type. Merge branch 'raise-alert-when-no-ack-file' of https://github.com/alphagov/notifications-api into raise-alert-when-no-ack-file
2018-01-12 16:10:09 +00:00
})
ensure sample SES callbacks and SNS subscription payloads are accurate in research mode and unit tests
2017-11-17 14:25:59 +00:00
def _sns_confirmation_callback():
return b'{\n "Type": "SubscriptionConfirmation",\n "MessageId": "165545c9-2a5c-472c-8df2-7ff2be2b3b1b",\n "Token": "2336412f37fb687f5d51e6e241d09c805a5a57b30d712f794cc5f6a988666d92768dd60a747ba6f3beb71854e285d6ad02428b09ceece29417f1f02d609c582afbacc99c583a916b9981dd2728f4ae6fdb82efd087cc3b7849e05798d2d2785c03b0879594eeac82c01f235d0e717736",\n "TopicArn": "arn:aws:sns:us-west-2:123456789012:MyTopic",\n "Message": "You have chosen to subscribe to the topic arn:aws:sns:us-west-2:123456789012:MyTopic.\\nTo confirm the subscription, visit the SubscribeURL included in this message.",\n "SubscribeURL": "https://sns.us-west-2.amazonaws.com/?Action=ConfirmSubscription&TopicArn=arn:aws:sns:us-west-2:123456789012:MyTopic&Token=2336412f37fb687f5d51e6e241d09c805a5a57b30d712f794cc5f6a988666d92768dd60a747ba6f3beb71854e285d6ad02428b09ceece29417f1f02d609c582afbacc99c583a916b9981dd2728f4ae6fdb82efd087cc3b7849e05798d2d2785c03b0879594eeac82c01f235d0e717736",\n "Timestamp": "2012-04-26T20:45:04.751Z",\n "SignatureVersion": "1",\n "Signature": "EXAMPLEpH+DcEwjAPg8O9mY8dReBSwksfg2S7WKQcikcNKWLQjwu6A4VbeS0QHVCkhRS7fUQvi2egU3N858fiTDN6bkkOxYDVrY0Ad8L10Hs3zH81mtnPk5uvvolIC1CXGu43obcgFxeL3khZl8IKvO61GWB6jI9b5+gLPoBc1Q=",\n "SigningCertURL": "https://sns.us-west-2.amazonaws.com/SimpleNotificationService-f3ecfb7224c7233fe7bb5f59f96de52f.pem"\n}' # noqa
Reference in New Issue Copy Permalink