Описание протокола взаимодействия с нашим TDS
- При старте прилаги, она формирует HTTP-запрос на сервер, в котором передает данные об устройстве. В ответ сервер возвращает токен сессии, который будет идентифицировать запросы приложения к серверу.
- Вслед за этим открывается WebView с зашитым адресом, по которому передается в GET-параметре токен. Сервер решает какой лендинг показать и перенаправляет на нужный лендинг.
Чтобы мы могли отследить попытки манипулирования приложением в ходе модерации и после неё, нам необходим механизм, позволяющий серверу однозначно оценить хит, который пришел из мобильного приложения. Для этого запросы, которые посылаются серверу содержат подпись. Точно также, как и везде в вебе, сессионные куки обычно содержат подпись, только эта подпись генерируется сервером.
В нашем случае подпись позволяет однозначно понять проводятся ли с приложением какие-то манипуляции или нет, потому что подделать подпись нереально. Если с IP-адреса приходит запрос, в котором некорректна подпись это означает, что IP-адрес можно смело блокировать и показывать лендинг, не вызывающий подозрений.
Т.к. мы не можем на стороне сервера получить разные данные об устройстве, которые необходимы, чтобы оценить хит и понять какой лендинг показывать, мы посылаем запрос №1.
Т.к. нам всё же нужно юзеру показать лендинг, мы посылаем запрос №2.
Первый запрос посылается как обычный HTTP-запрос, с помощью обычного HTTP-клиента (HttpURLConnection.html)
Второй запрос — открывается WebView с URL-ом в котормо передается токен сессии, который нужен серверу чтобы понять к какой сессии использования приложения отнести этот хит, а также подпись, гарантирующая что никаких манипуляций не было произведено.