Схема работы

Как работает SDK, как он взаимодействует с запросами приложения и ответами от вашего сервера / системы защиты.

Схема работы SDK

Схема работы:

  1. Приложение инициирует отправку запроса к ресурсу, который защищает Servicepipe.

  2. (Опциональный этап) если нужно определить страну устройства, SDK анализирует текущую локацию, опираясь на:

    • GPS (если у приложения есть доступ к геолокации);

    • таймзону устройства;

    • данные мобильной сети (доступно только на Android).

    Если нужно проверить признаки VPN, SDK анализирует сетевое окружение, опираясь на:

    • VPN-интерфейсы — например, tun* / utun* с нестандартным MTU;

    • системный proxy;

    • платформенные признаки активной сети (доступно только на Android, через ConnectivityManager.getNetworkCapabilities(activeNetwork)).

  3. (Опциональный этап) если ваше приложение запросило у API SDK данные о стране или признаках VPN, SDK передаёт их приложению.

  4. SDK, встроенный в сетевой слой приложения, добавляет к запросу служебные cookies Servicepipe и отправляет по адресу.

    (Опционально) если вы включили передачу данных о стране устройства или признаках VPN через HTTP-заголовки, SDK также добавит к запросу нужные HTTP-заголовки: x-cybert-mobile-country-code и/или x-cybert-mobile-vpn-signs.

    x-cybert-mobile-vpn-signs отправляется, только если SDK нашёл признаки VPN. Если их нет, заголовка не будет.

  5. Запрос поступает в систему защиты.

  6. Система защиты анализирует запрос и решает, что с ним делать. Возможны три сценария:

    • Пропуск — запрос легитимный; защита как reverse-proxy передаёт его на ваш сервер, сервер отвечает, ответ передаётся назад приложению.

    • Блокировка — запрос сделал бот; защита отдаёт в ответ ошибку HTTP 403.

    • Антибот-проверка — защита не уверена, бот отправил запрос или человек. Отдаёт в ответ редирект на JS-челлендж или CAPTCHA.

    Если это новая сессия, система защиты добавит к ответу служебную Set-Cookie с ID сессии. SDK её сохранит и будет добавлять к следующим запросам, пока срок жизни этой cookie не истечёт.

  7. Приложение получает ответ. Этот ответ сначала перехватывается SDK. Из него SDK считывает и сохраняет выставленные системой защиты cookies. Затем, если пришёл:

    • Любой другой ответ , кроме редиректа на JS-челлендж или CAPTCHA — SDK передаёт ответ дальше приложению.

    • Редирект на JS-челлендж или CAPTCHA — SDK открывает страницу в WebView/WKWebView (для пользователя это выглядит как всплывающее окно/экран) и даёт там пройти антибот-проверку.

    JS-челлендж проходится автоматически, пользователь видит только всплывшую на секунду иконку загрузки. CAPTCHA требует от него активных действий.

    Если приложение подписалось на события CAPTCHA, SDK отправляет событие, когда CAPTCHA-проверка началась, и ещё одно, если она успешно пройдена. В событии передаются статус, IP и ID запроса.

  8. (Опциональный этап) если был JS-челлендж или CAPTCHA, по его окончании SDK закрывает WebView/WKWebView.

    Если проверка была пройдена успешно, защита может выдать особую Set-Cookie, с которой пользователь какое-то время сможет проходить на ресурс без проверок. SDK сохраняет эту cookie и будет добавлять её в запросы, пока время жизни cookie не истечёт.

    Затем SDK отправляет исходный запрос с обновлёнными cookies ещё раз. Система защиты узнаёт пользователя, который только что проходил антибот-проверку, и:

    • пропускает запрос — если проверка показала, что пользователь не бот;

    • блокирует запрос — если проверка показала, что пользователь бот.