На публичной Wi‑Fi-сети приложение не входит в аккаунт, хотя устройство показывает подключение. Как отличить captive portal от сбоя API?
Нужно сравнить поведение приложения с доступом к обычному внешнему ресурсу и с той же операцией через мобильную сеть. Если до прохождения авторизации в сети HTTP-запросы перенаправляются на страницу входа, DNS отвечает нестандартно или доступ разрешён только к ограниченному набору адресов, вероятен captive portal, а не сбой API.
После подтверждения доступа в браузере следует повторить тот же сценарий в приложении. Если запрос к API начинает работать без изменения приложения и сервера, причина была в предварительной авторизации Wi‑Fi-сети.
Публичные Wi‑Fi-сети часто требуют принять условия, ввести код или пройти оплату до предоставления полного доступа в интернет. Для этого применяются captive portal: сеть пропускает только ограниченный трафик и перенаправляет пользователя на страницу авторизации.
Изначально такие механизмы рассчитывали главным образом на обычный HTTP-трафик. Современные операционные системы дополнительно выполняют собственные проверки доступности сети и могут показывать системный экран авторизации, но приложение не должно считать наличие значка Wi‑Fi доказательством доступа к своему API.
Состояние «устройство подключено к Wi‑Fi» означает наличие соединения с точкой доступа, но не гарантирует доступ в интернет или к конкретному серверу. До прохождения портала DNS, маршрутизация, прокси или фильтрация могут работать иначе, чем после авторизации.
Если приложение трактует такую ситуацию как ошибку сервера, пользователь получает misleading-сообщение вроде «неверный пароль» или «сервер недоступен». Автоматические повторы также могут создавать лишнюю нагрузку, а тестировщик рискует ошибочно завести дефект API.
Сначала нужно повторить операцию через мобильную сеть. Если через неё вход работает, это подтверждает зависимость от конкретной Wi‑Fi-сети, но ещё не доказывает наличие captive portal: причиной могут быть DNS-фильтрация, прокси, VPN или запрет нужных портов.
Затем на чистом подключении открывают в браузере обычный внешний HTTP-ресурс. Перенаправление на страницу авторизации, появление системного экрана входа или требование принять условия указывает на captive portal. HTTPS-запрос обычно нельзя безопасно перенаправить на портал: из-за проверки сертификата он может завершиться ошибкой, поэтому отсутствие перенаправления по HTTPS не исключает портал.
После авторизации проверяют тот же сценарий в приложении. Полезно сопоставить результаты для трёх состояний: до авторизации, сразу после неё и после отключения и повторного подключения к Wi‑Fi. Одновременно нужно проверить, что сам API доступен из другой сети и что ошибка не вызвана некорректным DNS, корпоративным прокси или настройками VPN.
Приложение может обнаруживать отсутствие сетевой доступности и предложить пользователю открыть системный экран авторизации, но не должно пытаться самостоятельно обходить портал или считать любой HTTP-ответ успешным подключением. Ограничение такого подхода в том, что универсального признака captive portal нет: сети могут использовать разные схемы, а системное обнаружение зависит от версии ОС и конфигурации сети.
В отеле Android-приложение показывало ошибку авторизации, а веб-сайт отеля открывался только после принятия условий. Через мобильную сеть вход в приложение работал.
Рассматривались варианты:
Выбрали последний вариант. Тест подтвердил, что до авторизации HTTP-доступ перенаправлялся на портал, а после неё тот же запрос успешно выполнялся. В приложении разделили сообщение о сетевой доступности и сообщение об ошибке учётных данных, поэтому пользователь перестал воспринимать проблему Wi‑Fi как неверный пароль.
1. Достаточно ли проверить, что браузер открывает страницу портала?
Нет. Это подтверждает наличие ограничений для браузера, но не доказывает, что приложение столкнулось именно с ними. Нужно проверить тот же сетевой маршрут приложения после авторизации и убедиться, что API доступен, а ошибка исчезает в тех же условиях.
2. Можно ли считать любой ответ с перенаправлением признаком captive portal?
Нет. Перенаправление может быть штатной логикой самого сервера, ошибкой прокси или результатом неверно настроенного маршрута. Важны адрес назначения, момент возникновения перенаправления, поведение в другой сети и исчезновение проблемы после прохождения авторизации в Wi‑Fi.
3. Почему проверка только HTTPS может не обнаружить портал?
Перенаправление HTTPS на другой сайт нарушает проверку сертификата, поэтому клиент обычно получает TLS-ошибку, а не страницу портала. Поэтому проверяют не только результат HTTPS-запроса к API, но и системное уведомление, браузерный доступ, обычный HTTP-ресурс и изменение поведения после авторизации.