Logowanie do portalu przechwytującego – co to jest i jak działa?

Logowanie do portalu przechwytującego to proces uwierzytelniania w sieci Wi‑Fi, który pojawia się przed uzyskaniem normalnego dostępu do internetu. W praktyce jest to specjalna strona logowania lub akceptacji regulaminu, automatycznie wyświetlana po połączeniu z daną siecią. Dobrze skonfigurowany portal przechwytujący zwiększa bezpieczeństwo, spełnia wymagania formalne (np. WiFi4EU) i poprawia komfort użytkowników. W dalszej części wyjaśniam, jak takie portale działają od strony technicznej i administracyjnej.

Czym jest portal przechwytujący i logowanie do niego?

Portal przechwytujący (ang. captive portal) to mechanizm w sieciach Wi‑Fi, który przejmuje pierwsze żądania HTTP/HTTPS użytkownika i przekierowuje je na dedykowaną stronę logowania. Użytkownik widzi wtedy ekran z regulaminem, formularzem logowania, czasem też z płatnością lub kodem dostępu. Dopiero po wykonaniu wymaganej akcji ruch tego użytkownika jest przepuszczany dalej do internetu.

Takie rozwiązanie stosuje się na lotniskach, w hotelach, szkołach, galeriach handlowych czy w projektach gminnych – w tym w sieciach finansowanych z programu WiFi4EU. Z punktu widzenia administratora to brama kontrolna: pozwala wymusić akceptację warunków, ograniczyć czas sesji, liczyć liczbę użytkowników czy spełnić wymogi prawne i grantowe.

Logowanie do portalu przechwytującego może polegać na wpisaniu adresu e‑mail, numeru pokoju, kodu vouchera, zalogowaniu przez media społecznościowe albo jedynie kliknięciu przycisku „Akceptuję regulamin”. Mechanizm ten nie ma nic wspólnego z bankowością czy aplikacjami podszywającymi się pod logowanie – jest elementem infrastruktury sieciowej, a nie złośliwego oprogramowania, choć błędnie skonfigurowany może wprowadzać użytkowników w konsternację.

Portal przechwytujący to warstwa pośrednia między urządzeniem użytkownika a internetem, która zarządza pierwszym etapem połączenia – od przechwycenia ruchu po autoryzację i nadanie pełnego dostępu.

Jak działa logowanie do portalu przechwytującego od strony technicznej?

Od chwili połączenia z siecią do momentu pojawienia się strony logowania zachodzi kilka kroków w warstwie IP, DHCP i HTTP/HTTPS. Nowoczesne systemy – jak Android czy ChromeOS – mają wbudowane moduły wykrywania portalu, które współpracują z siecią i jej serwerami. Kluczowe jest tu pojęcie „detekcji” portalu: system musi rozpoznać, że nie ma jeszcze pełnego dostępu do internetu, ale dostęp jest możliwy po przejściu przez stronę uwierzytelniania.

Na urządzeniach z Androidem za znaczną część tego procesu odpowiada moduł Network Stack (moduł Mainline aktualizowany przez Google). W jego skład wchodzi m.in. NetworkMonitor, klient DHCP i dedykowana aplikacja do logowania w portalu przechwytującym. Ten zestaw usług sprawdza dostępność internetu, wykrywa przekierowania i – gdy trzeba – uruchamia interfejs logowania.

Wykrywanie portalu przechwytującego w Androidzie

Android od wersji 5.0 wysyła tzw. „sondy łączności” – specjalne zapytania HTTP i HTTPS do znanych adresów testowych. Jeśli odpowiedź zostanie przekierowana na inną stronę, system uznaje, że znajduje się za portalem przechwytującym i wyświetla powiadomienie „Zaloguj się w sieci”. Ten mechanizm dobrze widać w publicznych Wi‑Fi, gdzie tuż po połączeniu wyskakuje okno logowania.

Od Androida 11 pojawia się ważne usprawnienie w postaci DHCP Option 114 opisanej w RFC7710bis. Sieć może przekazać w tej opcji adres URL do interfejsu Captive Portal API. Urządzenie po uzyskaniu adresu IP od razu pobiera plik JSON z tego adresu, a w nim informacje, czy sieć wymaga logowania, gdzie znajduje się strona logowania i jakie są parametry sesji. To znacznie zmniejsza liczbę fałszywych detekcji opartych jedynie na przekierowaniach HTTP.

Captive Portal API i JSON

Captive Portal API (opisany w RFC 8908) to standardowy sposób komunikacji między punktem dostępowym a urządzeniem klienta. Sieć wystawia punkt końcowy HTTPS zwracający JSON, a Android odczytuje z niego stan portalu. W odpowiedzi JSON można umieścić m.in.:

• captive – informację, czy uwierzytelnianie jest wymagane,
• user-portal-url – adres strony logowania lub płatności,
• venue-info-url – adres z informacjami o miejscu, np. hotelu lub lotnisku,
• seconds-remaining – czas pozostały do wygaśnięcia sesji w sekundach,
• x-android-use-custom-tabs – wartość włączającą użycie przeglądarki w trybie Custom Tabs w nowszych wersjach Androida.

Gdy pole captive jest ustawione na true, system pomija standardowe sondy HTTP/HTTPS i od razu otwiera aplikację logowania. Jeśli wartość to false, Android korzysta z klasycznych sond, ale oczekuje, że zarówno HTTP, jak i HTTPS będą działać poprawnie, zanim uzna sieć za w pełni online.

Custom Tabs w procesie logowania

Nowsze wersje Androida (od 12) mogą używać Custom Tabs do otwierania strony logowania. Oznacza to, że portal ładuje się w środowisku głównej przeglądarki użytkownika, a nie w uproszczonym WebView. Daje to kilka konkretnych korzyści: wsparcie dla DRM, poprawne działanie z VPN i prywatnym DNS, autouzupełnianie danych logowania i płatności oraz spójny interfejs znany z normalnego surfowania.

Warunkiem włączenia takiego trybu jest obecność w JSON pola x-android-use-custom-tabs z wartością równą co najmniej numerowi modułu CaptivePortalLogin z aktualizacji z stycznia 2026 (361335020). Dzięki temu tylko urządzenia z aktualnym modułem Network Stack przechodzą na przepływ z Custom Tabs, a starsze – pozostają przy klasycznym oknie systemowym.

Android używa dziś dwóch ścieżek wykrywania portali: klasycznych sond HTTP/HTTPS oraz nowoczesnego Captive Portal API z opcją DHCP 114 – to drugie podejście jest znacznie bardziej niezawodne w skomplikowanych sieciach.

Jak skonfigurować logowanie do portalu przechwytującego w ChromeOS?

Administrator zarządzający urządzeniami ChromeOS w firmie lub szkole może sterować wykrywaniem portali bezpośrednio w Google Admin Console. To istotne w sieciach korporacyjnych, gdzie ruch przechodzi przez zapory i serwery proxy – w takich środowiskach automatyczne sondy portalu bywają blokowane lub błędnie interpretowane.

Domyślnie w sieciach zarządzanych wykrywanie portalu jest wyłączone. W efekcie użytkownik po podłączeniu do Wi‑Fi z portalem nie widzi od razu powiadomienia o konieczności logowania i musi samodzielnie otworzyć stronę w przeglądarce. W sieciach gościnnych lub hotelowych znacznie lepiej sprawdza się tryb, w którym system automatycznie wyświetla powiadomienie i otwiera stronę logowania.

Włączanie wykrywania portalu przechwytującego w konsoli Google

Aby włączyć wykrywanie portalu przechwytującego dla konkretnej sieci Wi‑Fi w ChromeOS, wykonaj te kroki jako administrator:

1. Zaloguj się do konsoli administracyjnej Google na konto z uprawnieniami administratora urządzeń.
2. Przejdź do sekcji „Urządzenia”, a następnie „Sieci”.
3. Wybierz jednostkę organizacyjną, dla której chcesz zmienić ustawienia (np. dział gościnny, szkoła, filia).
4. Odszukaj profil sieci Wi‑Fi i kliknij jego nazwę, aby edytować konfigurację.
5. Przewiń do sekcji „Ustawienia portalu przechwytującego”.
6. Wybierz „Wykrywanie portalu przechwytującego włączone”. W razie potrzeby zaznacz opcję „Tylko sondy internetowe HTTP”, jeśli Twoja zapora utrudnia sondy HTTPS.
7. Zapisz zmiany – konfiguracja zostanie automatycznie rozpropagowana na zarządzane urządzenia ChromeOS.

Po tej zmianie użytkownik po podłączeniu do sieci z portalem zobaczy jasne powiadomienie, że musi się zalogować, a strona logowania otworzy się automatycznie w przeglądarce. To znacząco redukuje liczbę zgłoszeń „Wi‑Fi nie działa”, gdy w rzeczywistości użytkownik po prostu nie przeszedł jeszcze logowania.

Typowe problemy i ich przyczyny

Jeśli urządzenia z ChromeOS zgłaszają komunikaty „Sieć niedostępna” lub „Urządzenie nie może połączyć się z żadną siecią bezprzewodową”, przyczyna często leży w konfiguracji zapory. Hosty wykorzystywane do sond łączności muszą być dostępne przez HTTP (port 80), w przeciwnym razie system nie jest w stanie rozpoznać, że internet jest osiągalny.

W sieciach, w których działa inspekcja TLS/SSL, trzeba wprowadzić odpowiednią listę dozwolonych nazw hostów – tak, aby Network Stack w ChromeOS mógł bez przeszkód wykonywać testy łączności i wyświetlać portal logowania we właściwym momencie.

Jak skonfigurować portal przechwytujący dla WiFi4EU?

Sieci budowane w ramach programu WiFi4EU mają dodatkowe wymogi. Portal uwierzytelniania musi spełniać kryteria techniczne i wizualne, a także generować dane pomiarowe używane do weryfikacji działania sieci. Logowanie użytkowników do takiego portalu nie jest jedynie wygodą, ale częścią rozliczenia dotacji.

Unijna agencja (obecnie HADEA) sprawdza zdalnie dwa warunki: obecność elementu identyfikacji wizualnej WiFi4EU na portalu oraz co najmniej 10 różnych urządzeń klienckich, które faktycznie zalogowały się do tej sieci. Dopiero wtedy projekt traktowany jest jako działający.

Snippet JavaScript i zmienne WiFi4EU

Warunkiem prawidłowego działania pomiarów jest instalacja tzw. „snippetu” JavaScript w kodzie portalu. Należy go umieścić w górnej części sekcji <head>, natychmiast po otwarciu znacznika. Przykładowy blok wygląda następująco:

Kod WiFi4EU musi znaleźć się tuż po znaczniku <head> i zawierać zmienne wifi4euTimerStart, wifi4euNetworkIdentifier i wifi4euLanguage oraz skrypt wifi4eu.min.js z domeny collection.wifi4eu.ec.europa.eu.

Taka konstrukcja pozwala systemowi unijnemu mierzyć czas ładowania portalu, rozpoznawać konkretną sieć (UUID) oraz dopasować wersję językową identyfikacji wizualnej. Administrator nie musi umieszczać kodu w innych częściach strony – warunkiem jest jego obecność na samej górze nagłówka.

Element identyfikacji wizualnej WiFi4EU

Sama obecność skryptu nie wystarcza. Na stronie musi znajdować się znacznik zastępczy, w który snippet wstawi właściwy baner. Zgodnie z wymaganiami należy umieścić w kodzie portalu element:

Element identyfikacji wizualnej WiFi4EU musi być widoczny po załadowaniu strony, mieć proporcjonalny rozmiar i używać znacznika <img id="wifi4eubanner"> jako miejsca wstawienia grafiki.

Ten znacznik powinien spełniać kilka warunków: mieć określoną szerokość i wysokość w CSS, znajdować się w widocznym obszarze strony (bez przewijania), nie być zakryty innymi elementami i nie mieć obniżonej przezroczystości. W widoku o szerokości poniżej 600 px baner powinien zajmować co najmniej 90% szerokości okna, a powyżej 600 px – minimum 50%.

Konfiguracja portalu w cnMaestro krok po kroku

W projektach WiFi4EU często wykorzystuje się kontroler cnMaestro i punkty dostępowe serii cnPilot E. Konfiguracja portalu przechwytującego odbywa się z poziomu interfejsu webowego i obejmuje kilka etapów:

1. Po zalogowaniu do cnMaestro rozwiń menu po lewej stronie i wybierz „Guest Access Portal” w sekcji „Services”.
2. Załaduj plik z logo WiFi4EU (np. wifi4eulogo.png) i – w razie potrzeby – połącz go z herbem gminy lub miasta.
3. Ustaw tło (Logo Background), przesuwając suwak tak, aby dopasować kolor do wytycznych wizualnych projektu.
4. W sekcji WiFi4EU zaznacz opcję „Enable”, wybierz język polski w polu „Language” oraz włącz tryb „Self-test Modus” na etapie testów (później należy go wyłączyć po uzyskaniu docelowego UUID).
5. Włącz „Show Logo” i zapisz ustawienia przyciskiem „Save”.
6. Przejdź do zakładki „Content”, dodaj polskie treści (regulamin, klauzule, instrukcje) oraz wypełnij pole „On Success Redirect to URL”, podając adres, na który użytkownik ma zostać przekierowany po zalogowaniu.
7. Każdą zmianę zatwierdzaj przyciskiem „Save”, bo portal zapisuje konfigurację dopiero po tej operacji.

Po stronie programu WiFi4EU wymagane jest również uzyskanie Network UUID na podstawie adresu IP (często stosuje się 0.0.0.0/0 jako zakres) oraz URL portalu przechwytującego. Ten identyfikator łączy konkretną instalację z danymi zbieranymi przez snippet.

Typowy komunikat z INEA i co z niego wynika

W praktyce wiele gmin dostaje e‑mail z systemu WiFi4EU z informacją, że nie udało się zdalnie potwierdzić dwóch warunków: obecności elementu identyfikacji wizualnej na portalu i zalogowania co najmniej dziesięciu użytkowników. W takiej sytuacji trzeba zweryfikować dwie rzeczy: czy na stronie faktycznie znajduje się znacznik id="wifi4eubanner" w widocznej części i czy co najmniej 10 urządzeń różnych użytkowników rzeczywiście skorzystało z sieci.

Bez tych elementów sieć, choć lokalnie wydaje się w pełni sprawna, z perspektywy systemu monitorującego WiFi4EU wciąż nie spełnia kryteriów rozliczenia bonu – co blokuje płatność za projekt.

Jak połączyć kwestie bezpieczeństwa z użyciem portali przechwytujących?

Portale przechwytujące kojarzą się użytkownikom z ekranami logowania, więc naturalnie pojawia się pytanie: gdzie przebiega granica między legalnym mechanizmem sieciowym a zagrożeniami w stylu Android/Spy.Agent.SI? Wspomniane zagrożenie podszywa się pod popularną aplikację (np. Flash Player), uzyskuje prawa administratora i wyświetla fałszywe ekrany logowania do aplikacji bankowych, aby kraść dane.

Różnica jest zasadnicza: legalny portal przechwytujący działa na poziomie sieci (router, kontroler, firewall), a nie jako aplikacja w systemie użytkownika. Strona logowania pojawia się tylko po podłączeniu do konkretnej sieci Wi‑Fi, a nie w losowych chwilach, i dotyczy dostępu do internetu, a nie np. konta bankowego. Z kolei złośliwe oprogramowanie manipuluje ekranem samego urządzenia, przechwytuje SMS‑y czy kody autoryzacyjne i nie jest związane z parametrami sieci.

Bezpieczeństwo logowania do portalu przechwytującego zaczyna się od dwóch nawyków: instalowania aplikacji wyłącznie z zaufanych sklepów oraz korzystania z publicznych Wi‑Fi wyłącznie tam, gdzie portal logowania wygląda spójnie z miejscem, w którym się znajdujesz.

Dobre praktyki dla administratorów

Administrator, który projektuje portal przechwytujący, powinien zadbać zarówno o wygodę użytkownika, jak i o odporność na nadużycia. Warto trzymać się kilku zasad:

• stosować HTTPS na stronach logowania i interfejsach API,
• jasno oznaczać nazwę obiektu (hotel, uczelnia, gmina) na stronie portalu,
• wdrożyć Captive Portal API i opcję DHCP 114, aby zmniejszyć ryzyko błędnych detekcji,
• testować działanie na różnych systemach (Android, ChromeOS, Windows, iOS),
• monitorować logi portalu pod kątem nietypowych prób logowania lub masowego nadużycia.

Po stronie użytkowników dobrym uzupełnieniem jest korzystanie z aplikacji antywirusowych na smartfonach, które potrafią wykrywać złośliwe aplikacje typu Android/Spy.Agent.SI, śledzące logowania i przechwytujące SMS‑y z kodami bankowymi.

Jak porównać różne mechanizmy logowania do portalu przechwytującego?

Różne środowiska – Android, ChromeOS i projekty grantowe takie jak WiFi4EU – podchodzą do logowania w portalach przechwytujących nieco inaczej. Warto zestawić najważniejsze cechy w prostej tabeli:

Dzięki takiemu porównaniu możesz łatwiej zaplanować architekturę portalu przechwytującego, który będzie współpracował z urządzeniami mobilnymi różnych typów, a jednocześnie spełni formalne wymagania finansujących instytucji i nie obniży komfortu użytkowników.