Я вручную реализую портал захвата Wi-Fi. У меня все в значительной степени работает, НО одна загвоздка: я хочу, чтобы все видели всплывающее окно с захватным порталом своих мобильных ОС (или компьютерных ОС) для безупречного опыта.
Поскольку у каждого из них есть свой извращенный способ сделать это, я, похоже, не могу получить согласованный кроссплатформенный опыт.
Чтобы это произошло, могу ли я помочь описать (1) какие URL-запросы от клиентов WiFi необходимо перенаправлять на страницу входа в систему, и / или (2) какую конфигурацию веб-сервера nginx или apache можно использовать для перенаправления WiFi клиентов на страницу входа?
Моя страница входа в портал авторизации в этом примере: http: //captiveportal.lan . Вот некоторые из операционных систем, для которых я пытаюсь решить эту проблему.
Android 4/5/6
RedirectMatch 302 /generate_204 http://captiveportal.lanПредыдущие версии Android
iOS 8
Apache .htaccess:
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^CaptiveNetworkSupport(.*)$ [NC]
RewriteRule ^(.*)$ http://captiveportal.lan [L,R=302]
nginx:?
Предыдущие версии iOS
Windows Phone
RedirectMatch 302 /ncsi.txt http://captiveportal.lan
Windows 7 \ 8 \ 10
Mac OS
Amazon Kindle - есть ли всплывающее окно?
Все мобильные ОС просто проверяют веб-страницу, чтобы решить, находятся ли они за адаптивным порталом или нет.
Механизм такой:
Кроме того, для iOS вам необходимо иметь домен для вашей сети Wi-Fi, поскольку он предполагает, что сеть без домена без доступа является домашней сетью, и просто помечает ее как Нет сети вместо Captive Portal.
Просто убедитесь, что вы явно перенаправили следующие URL-адреса на ваш захватывающий портал с HTTP Success:
Android / Chromebook:
iOS 6:
IOS 7:
iOS 8/9:
Windows
Многие поставщики также начали использовать пользовательский агент «CaptiveNetworkSupport», хотя он не так распространен, как метод URL выше. Просто проверьте этот UA и всегда указывайте ему свою страницу портала ... хотя не работает на 100%.
Я использую метод URL, и он работает нормально.
Amazon Kindle (Огонь)
Amazon Kindle (Fire) выполняет следующий запрос, и если его невозможно получить «... он предполагает, что пользователь должен войти в систему, и вызывает экран входа в систему.»:
iOS 8.4
Для последней версии iOS мне пришлось сопоставить все URI для запросов к http://captive.apple.com - не просто "/hotspot-detect.html".
Клиенты iOS 8.4 отправляют запросы со случайно сгенерированными URI (например, "/xmqPyZUv/3r8jTjv8.html" и "/7exN0TV7q0COX0/eKlBU8baU2tape/fjXUzDHBdE6W0O/BGbw7iYU2DVBlTxtml/bgbw7iYU2DVBlTmlEs для обнаружения следующих доменов) в следующих доменах.