В последних УТМ реализован раздел проактивных уведомлений (Сообщения и уведомления), в который из ФСРАР поступают уведомления о нарушениях.
Хотим научиться их вычитывать, что бы затем уведомлять клиентов о "письмах счастья", нужен совет как это можно сделать.
В документации и в swagger про способ их извлечения не написано, сервис рассчитан только на просмотр из веб-интерфейса.
Сами уведомления находятся по адесу localhost:8080/app/services/proactive/XXX, где ХХХ - это номер уведомления
Через "curl -X GET http://localhost:8080/app/services/proactive/" и "curl -X GET http://localhost:8080/opt/out" они не вычитываются
OlegON➤ Я имел ввиду на страничку localhost:8080/app/services/proactive/XXX долбиться... А на страничку выше curl нельзя попасть? А то там-то номера есть...
вот что дает "curl -X GET http://localhost:8080/app/services"
Неправильно ты дядя Федор...
Зачем тебе эта страничка? Инструменты веб-мастера открой и посмотри, как грузится та, которая тебе нужна. Возможно, что стоит какая-то хитрая защита, тогда "ой", возможно, что ты ее легко заберешь, например, подставив referer, и расскажешь нам, как это делать.
OlegON➤ Неправильно ты дядя Федор...
Зачем тебе эта страничка? Инструменты веб-мастера открой и посмотри, как грузится та, которая тебе нужна. Возможно, что стоит какая-то хитрая защита, тогда "ой", возможно, что ты ее легко заберешь, например, подставив referer, и расскажешь нам, как это делать.
Вызывается "http://localhost:8080/api/query/proxy/gateway/proactive/api/v1/utm-proxy/services?page=1&size=10&sortField=id&sortDirection=desc"
В Referrer указан "http://localhost:8080/app/services/proactive"
В Referrer Policy стоит strict-origin-when-cross-origin
Прочитать единичное уведомление в итоге получилось через
"curl -X GET http://localhost:8080/api/query/proxy/gateway/proactive/api/v1/utm-proxy/services/322001"
а вот получить список чет пока не получается, ругается 400 ошибкой на любой параметр списка
_R2D2_➤ "curl -X GET http://localhost:8080/api/query/proxy/gateway/proactive/api/v1/utm-proxy/services/322001"
Увидел знакомый адрес, не смог не прокомментировать.
Тут: https://olegon.ru/showthread.php?t=38538 я описывал как утм проверяет мчд и получает список точек продаж для доверенного физ лица с мчд. Тут примерно та же петрушка. SPA УТМа шлет запрос на апи контроллер универсальных запросов утм (... /api/query), тот проксирует его на соответствующий сервис егаис (действие proxy контроллера, все что за proxy - адрес сервиса на стороне рара вместе с параметрами). Адрес сервиса егаис описывался по указанной выше ссылке (отличается для контуров тест и прод). В предыдущем варианте был универсальный post запрос, в текущем - универсальный get. И что-то мне подсказывает, таких неизведанных универсальных запросов ещё тьма.
Тут надо выдергивать запрос со SPA УТМа на получение списка айдишников уведомлений (предполагаю, 322001 как раз такой айди) чтобы по нему получать внутрянку - скорее всего и такой запрос отправляется, ищите. Будет работать только при наличии работающего контура УТМ.
Вариант 2. Обзаведшись заветными адресами попытаться стучаться напрямую в рар (для нужного контура утм сервера разные) по адресам, следующим за proxy полученных. Только там mtls - без серта не пустят. Для тех, кто будет говорить, что это дичь, приведу свои соображения:
1. Мчд и (или) генерация рса сертификата для нового торгового объекта. Механизмы схожие, работает без наличия сертификата рса ибо его ещё нет. Идёшь по адресу - просят серт (или даже не просят, возможно, страница не отображается). Т. Е. механизм работает с общим для всех сертом. Собственно, его открытая часть прекрасно ловится в wireshark.
2. Раз используется общий рса серт для создания канала, но есть необходимость идентифицировать участника, наверняка УТМ дописывает что-то идентифицирующее в посылку. Без сертификата ГОСТ оно не работает - значит Инн. В адресе его нет - значит либо дописывает к отправляемым данным (но это работало бы только для post, а тут get) либо в заголовки. Скорее всего в заголовки. Это логично - не зря есть контроллер универсальных запросов - он может и пользователя идентифицировать и серт прикрепить
В общем делов-то всего ничего - получить адреса, понять что там перекидывается в рар, попросить в раре серт для обращения с их сервиса и и можно получать уведомления без УТМ.