Я ищу рекомендации по обеспечению безопасности входящих сообщений. Меня особенно беспокоит время простоя нашего HTTP-прослушивателя, будь то из-за запланированных или незапланированных событий, а также возможность того, что проблемы с маршрутизацией вне нашего контроля могут помешать Twilio даже добраться до нашего сервера.
Экран App Monitor на сайте Twilio содержит подробную информацию обо всех входящих сообщениях, которые не удалось доставить по URL-адресу запроса, но, если я не пропустил его, я не вижу доступа к нему через API.
Я думал об отправке фиктивного сообщения с указанием URL-адреса обратного вызова в качестве средства подтверждения того, что Twilio может получить доступ к нашему сайту, но даже при одном сообщении каждую минуту он все равно мог пропускать короткие отключения из-за временных проблем с маршрутизацией. Резервный URL-адрес тоже не решает моих проблем, поскольку на него могут влиять те же проблемы, что и для основного URL-адреса запроса.
Единственный способ, которым я могу это сделать, - это периодически использовать ресурс списка сообщений для сравнения с базой данных полученных сообщений на HTTP-прослушивателе, но мне не нравится тот факт, что он ограничен фильтрацией с точностью до 24 часов. В идеале я бы хотел запускать эту процедуру «перекрестной проверки» каждые 5–10 минут или около того и указывать диапазон временных меток, чтобы минимизировать количество ненужных обращений к ЦП / базе данных.
Кто-нибудь придумал для этого какие-нибудь умные решения?
