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

Logowanie do portalu przechwytującego to ekran, który widzisz po podłączeniu do Wi‑Fi, zanim uzyskasz dostęp do internetu – służy do akceptacji regulaminu, płatności lub uwierzytelnienia użytkownika. Działa w ten sposób, że sieć tymczasowo „przechwytuje” cały ruch HTTP/HTTPS i przekierowuje go na stronę logowania, dopóki urządzenie nie zostanie poprawnie autoryzowane. Jeśli chcesz lepiej zrozumieć, jak to jest realizowane w praktyce na Androidzie, ChromeOS czy w projektach WiFi4EU i jak wpływa to na bezpieczeństwo, przeczytaj dalszą część artykułu.

Czym jest portal przechwytujący?

Portal przechwytujący to specjalnie skonfigurowana strona logowania, która pojawia się po połączeniu z publiczną lub firmową siecią Wi‑Fi. Z technicznego punktu widzenia sieć traktuje każde nowe urządzenie jako „niezalogowane” i przepuszcza jedynie ruch do serwera portalu, blokując zwykły dostęp do internetu, dopóki użytkownik nie zaakceptuje warunków lub nie poda danych logowania. Takie rozwiązanie stosują lotniska, hotele, dworce, galerie handlowe, samoloty, a także gminne sieci w programach typu WiFi4EU.

W odróżnieniu od klasycznego okna logowania do routera, portal przechwytujący działa po stronie warstwy sieciowej – jest widoczny dla każdego nowego klienta w danej podsieci. Po zalogowaniu sieć oznacza urządzenie jako uwierzytelnione, np. na podstawie adresu MAC, adresu IP lub sesji w systemie RADIUS, i od tego momentu pozwala na swobodny ruch do internetu. Jeżeli sesja wygaśnie (po czasie, przekroczeniu limitu danych lub wylogowaniu), proces logowania jest powtarzany.

Portal przechwytujący przejmuje pierwsze żądania HTTP/HTTPS nowego klienta i wymusza wyświetlenie własnej strony, zanim dopuści ruch do reszty internetu.

Jak działa logowanie do portalu przechwytującego w sieci Wi‑Fi?

Podstawowy scenariusz jest podobny w hotelu, w firmie z siecią gościnną czy w projekcie miejskiego Wi‑Fi: po podłączeniu do SSID urządzenie otrzymuje adres IP z DHCP, ale próba wejścia na dowolną stronę kończy się przekierowaniem do ekranu logowania. Za tym mechanizmem stoją punkty dostępowe, kontrolery lub brama z włączoną funkcją „captive portal”, a ruch użytkownika przechodzi przez serwer, który decyduje, czy klient ma już otwartą sesję.

Jak Android wykrywa portal przechwytujący?

Od wersji 5.0 urządzenia z Androidem aktywnie sprawdzają, czy za siecią Wi‑Fi nie stoi portal przechwytujący. System wysyła tzw. sondy HTTP/HTTPS do znanych adresów testowych (np. connectivitycheck.gstatic.com) i analizuje odpowiedź – jeśli zamiast prostego „OK” pojawi się przekierowanie, Android zakłada, że sieć wymaga logowania i wyświetla powiadomienie z informacją, że trzeba zalogować się do sieci. To zadanie realizuje komponent NetworkMonitor, który współpracuje z aplikacją logowania w portalu.

Od Androida 11 ten mechanizm został rozszerzony o obsługę DHCP Option 114 opisaną w RFC7710bis. Serwer DHCP może w tej opcji podać adres URL interfejsu Captive Portal API – jeśli urządzenie go otrzyma, pobiera plik JSON z informacją, czy sieć jest „captive”, jaki jest adres strony logowania i np. ile czasu pozostało do końca sesji. Dzięki temu wykrywanie portalu nie opiera się wyłącznie na kruchych przekierowaniach HTTP.

Jak wygląda wykrywanie na ChromeOS?

Na urządzeniach z ChromeOS administrator może sterować wykrywaniem portali przechwytujących z poziomu konsoli administracyjnej Google. Dla sieci zarządzanych (np. wewnętrznych sieci szkolnych) wykrywanie jest domyślnie wyłączone, bo lokalne zapory i serwery proxy często zakłócają działanie sond. Gdy administrator doda profil sieci Wi‑Fi, może w sekcji „Ustawienia portalu przechwytującego” wybrać, czy urządzenia mają automatycznie otwierać stronę logowania, czy użytkownik ma robić to ręcznie w przeglądarce.

W praktyce wygląda to tak: po połączeniu z SSID z włączonym wykrywaniem ChromeOS wyświetla komunikat „Zaloguj się do sieci”, a okno logowania otwiera się w przeglądarce. Jeśli wykrywanie jest wyłączone, użytkownik widzi jedynie ikonę braku internetu i musi sam otworzyć dowolną stronę – dopiero przekierowanie zadziała jako „ręczne” wejście na portal.

Jak działa logowanie krok po kroku?

Pod względem technicznym logowanie do portalu przechwytującego to prosty przepływ: blokowanie ruchu, przekierowanie na stronę logowania, uwierzytelnienie i odblokowanie dostępu. Z punktu widzenia użytkownika jest to kilka czytelnych kroków, które warto przeanalizować:

1. Urządzenie łączy się z siecią Wi‑Fi i dostaje adres IP od serwera DHCP.
2. System (Android lub ChromeOS) wykrywa brak pełnego dostępu do internetu i proponuje otwarcie strony logowania.
3. Portal przechwytujący wyświetla regulamin, formularz logowania lub przycisk „Zgadzam się / Połącz”.
4. Po akceptacji warunków lub podaniu danych serwer tworzy sesję użytkownika i oznacza go jako zalogowanego.
5. Następne zapytania HTTP/HTTPS nie są już przechwytywane – urządzenie ma klasyczny dostęp do internetu.

Jaką rolę pełni Captive Portal API?

Captive Portal API opisany w RFC 8908 to standard, który ma uporządkować komunikację między siecią a urządzeniem użytkownika w kwestii logowania do portalu. Zamiast zgadywać na podstawie przekierowań HTTP, telefon lub laptop dostaje jednoznaczną odpowiedź w formacie JSON: czy portal jest aktywny, gdzie leży adres strony logowania i jakie są parametry sesji (czas trwania, limity danych, dodatkowe informacje o miejscu).

Android 11 i nowsze wersje pobierają taki plik JSON na podstawie adresu URL przekazanego w DHCP Option 114. Jeśli odpowiedź zawiera pole „captive”: true, system od razu otwiera stronę logowania, bez wykonywania dodatkowych sond HTTP/HTTPS. Gdy „captive” przyjmuje wartość false, Android uznaje, że użytkownik jest online, ale weryfikuje to jeszcze standardowymi sondami, aby wykryć ewentualne problemy z łącznością.

Captive Portal API pozwala sieciom wprost powiedzieć urządzeniom: „tu jest mój portal, tu jest adres logowania, tu znajdziesz informacje o miejscu i ważności sesji”.

W odpowiedzi JSON mogą znaleźć się m.in. takie atrybuty: „user-portal-url” (adres logowania), „venue-info-url” (link do strony z informacjami o miejscu, np. lotnisku), „seconds-remaining” (czas do końca sesji) oraz „x-android-use-custom-tabs”, który wskazuje, czy Android ma użyć niestandardowych kart Chrome zamiast prostego okna WebView.

Jak portal przechwytujący działa w projektach WiFi4EU?

Program WiFi4EU wymaga, aby każda instalacja miejskiej sieci Wi‑Fi miała własny portal uwierzytelniania, spełniający konkretne wymogi techniczne i wizualne. Sieć musi mieć przypisany Network UUID, a portal – specjalny kod (snippet JavaScript) umieszczony w sekcji

strony logowania. Ten fragment uruchamia mechanizm pomiaru jakości usługi oraz ładuje element identyfikacji wizualnej WiFi4EU.

W praktyce instalator korzystający z platformy cnMaestro i punktów dostępowych serii cnPilot konfiguruje tzw. Guest Access Portal, wgrywa logo (plik wifi4eulogo.png lub połączenie z herbem gminy), ustawia język polski, włącza tryb WiFi4EU i uzupełnia tekst regulaminu oraz adres przekierowania po udanym logowaniu. Po wpisaniu adresu portalu i zakresu podsieci (często stosowane jest 0.0.0.0/0) system WiFi4EU generuje Network UUID, który wiąże portal z daną instalacją.

Jak dodać snippet WiFi4EU?

We wskazówkach WiFi4EU opisano tzw. snippet – fragment kodu JavaScript, który musi znaleźć się na każdej stronie portalu uwierzytelniania. Umieszcza się go tuż po znaczniku <head>, aby pomiary zaczynały się już w momencie ładowania strony. Kod zawiera zmienne takie jak wifi4euTimerStart, wifi4euNetworkIdentifier i wifi4euLanguage, a następnie ładuje bibliotekę z adresu collection.wifi4eu.ec.europa.eu.

W przypadku portalu wbudowanego w cnMaestro snippet jest już zaszyty w oprogramowaniu – integrator nie musi samodzielnie wklejać skryptu do kodu HTML. Jedynym obowiązkiem jest poprawne uzyskanie kodu UUID na podstawie adresu IP portalu i jego URL oraz upewnienie się, że urządzenia końcowe faktycznie korzystają z tej strony przy logowaniu.

Jak dodać element identyfikacji wizualnej?

Oprócz snippetu WiFi4EU wymaga, aby na stronie portalu znajdował się element identyfikacji wizualnej – baner, który jest automatycznie wstrzykiwany przez skrypt. Aby to było możliwe, w kodzie HTML trzeba umieścić znacznik zastępczy:

<img id=”wifi4eubanner”> – element musi być widoczny, nieprzykryty, z nadanymi wymiarami i znajdować się w obszarze widocznym po załadowaniu strony.

Styl tego elementu (rozmiar, położenie) definiujesz w CSS. Dla małych ekranów (szerokość poniżej 600 px) baner powinien zajmować co najmniej 90% szerokości widocznego obszaru, a dla większych – przynajmniej 50%. Jeśli baner nie jest widoczny lub ma zbyt małe wymiary, kontroler WiFi4EU może uznać, że wymóg identyfikacji wizualnej nie został spełniony.

Jak spełnić warunek minimum 10 użytkowników?

Zespół programu WiFi4EU wymaga także, aby do portalu uwierzytelniania podłączyło się co najmniej 10 różnych urządzeń końcowych. Chodzi o realne użycie sieci, a nie tylko formalne wdrożenie sprzętu. Przed ostatecznym potwierdzeniem instalacji warto zaprosić pracowników urzędu, szkoły lub mieszkańców do testowego logowania – każde urządzenie musi przejść przez portal i zaakceptować regulamin.

Jeśli w powiadomieniu z WiFi4EU otrzymasz informację o niespełnieniu warunków, trzeba w pierwszej kolejności sprawdzić, czy baner jest widoczny na portalu, a następnie, czy liczba unikalnych logowań przekroczyła wymagane 10 urządzeń. Dopiero po spełnieniu obu warunków system uzna sieć za działającą zgodnie z umową dotacji.

Jak zadbać o bezpieczeństwo logowania do portalu przechwytującego?

Publiczne portale przechwytujące bywają wykorzystywane w atakach – użytkownik widzi ekran logowania i często bezrefleksyjnie wpisuje dane, bo proces wygląda znajomo. Zdarzają się także złośliwe aplikacje podszywające się pod strony logowania do banków, jak malware Android/Spy.Agent.SI wykrywane przez firmę Eset. Tego typu oprogramowanie potrafi przechwytywać SMS-y z kodami autoryzującymi przelewy i w tło wysyłać je na serwery przestępców.

W przypadku zwykłego użytkownika najważniejsze jest zachowanie rozsądku: w publicznym Wi‑Fi nie należy logować się do bankowości ani podawać haseł do krytycznych usług, jeśli portal nie używa HTTPS lub wygląda podejrzanie. Trzeba zwracać uwagę na pasek adresu, certyfikat, obecność literówek w domenie, a także na zbyt natarczywe prośby o dane osobowe, które nie są potrzebne do bezpłatnego dostępu do internetu.

Warto też chronić sam smartfon lub tablet – instalować aplikacje wyłącznie z oficjalnego sklepu, odrzucać żądania nieuzasadnionych uprawnień administracyjnych i używać oprogramowania antywirusowego, które w 2026 r. jest dostępne nawet w bezpłatnych edycjach. Dzięki temu ewentualna fałszywa aplikacja „Flash Player”, która podszywa się pod prawdziwą usługę, ma mniejszą szansę na zainstalowanie się z prawami administratora i przechwycenie danych logowania do portalu czy banku.

Jak administrator może ograniczyć ryzyko?

Osoba projektująca sieć gościnną powinna zadbać o szyfrowanie HTTPS na stronie portalu, prawidłowe certyfikaty oraz maksymalne uproszczenie procesu logowania – wystarczy przycisk „Akceptuję regulamin”, bez zbędnego zbierania danych. Captive Portal API pomaga w wiarygodnym wykrywaniu portalu, co zmniejsza liczbę błędnych komunikatów i sytuacji, w których użytkownik nie wie, dlaczego internet „nie działa”. Na urządzeniach z Androidem rolę techniczną odgrywa tu moduł Mainline odpowiedzialny za stos sieciowy i aplikację logowania, który Google aktualizuje niezależnie od wersji systemu.

W kontekście infrastruktury warto mieć świadomość, że obsługą dostępności internetu, sondami HTTP/HTTPS i wykrywaniem portalu zajmuje się wewnętrznie komponent NetworkMonitor – działa on w ramach aktualizowanego modułu Network Stack i komunikuje się z przeglądarką oraz aplikacją logującą użytkownika. To dzięki temu Android może dostosowywać się do nowych typów portali przechwytujących bez konieczności wymiany całego systemu, a użytkownicy widzą spójny, bezpieczny ekran logowania nawet w złożonych środowiskach firmowych.