Co to jest błąd 401?

Błąd 401, określany również jako 401 Unauthorized, jest kodem odpowiedzi serwera informującym o problemie z uwierzytelnieniem. Pojawia się, gdy użytkownik, przeglądarka lub aplikacja próbuje otworzyć chroniony zasób, ale nie przekazuje prawidłowych danych logowania.

Komunikat może wystąpić podczas logowania do panelu, otwierania strony zabezpieczonej hasłem, korzystania z aplikacji internetowej albo wysyłania zapytania do API. Nie zawsze oznacza wpisanie błędnego hasła. Przyczyną może być także wygasła sesja, brak tokenu, nieprawidłowa konfiguracja serwera lub konflikt z mechanizmem zabezpieczającym stronę.

W zależności od zastosowanego mechanizmu serwer może oczekiwać między innymi:

• nazwy użytkownika i hasła,
• aktywnej sesji logowania,
• ciasteczka identyfikującego użytkownika,
• tokenu dostępu,
• klucza API,
• certyfikatu klienta,
• poprawnego nagłówka uwierzytelniającego.

Błąd jest przekazywany za pomocą protokołu HTTP. Przeglądarka może wtedy wyświetlić komunikat 401, formularz logowania albo przygotowaną przez właściciela strony podstronę z informacją o braku dostępu.

Warto wiedzieć. Angielska nazwa Unauthorized może sugerować brak uprawnień. W praktyce kod 401 dotyczy przede wszystkim braku prawidłowego uwierzytelnienia. Problemy z uprawnieniami częściej sygnalizuje kod 403.

Jak działa odpowiedź 401?

Komunikacja internetowa opiera się na żądaniach i odpowiedziach. Klient wysyła żądanie do serwera, a serwer zwraca zasób albo kod opisujący wynik operacji.

Jeżeli żądanie dotyczy chronionego adresu i nie zawiera odpowiednich danych, serwer może odpowiedzieć w następujący sposób:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer

Nagłówek WWW-Authenticate informuje klienta, jaki sposób uwierzytelnienia jest wymagany. W tym przykładzie serwer oczekuje tokenu typu Bearer. W innych przypadkach może wskazać między innymi uwierzytelnienie Basic, Digest lub inny mechanizm obsługiwany przez aplikację.

Klient może następnie ponowić żądanie i przesłać dane w nagłówku Authorization. Jeśli dane będą prawidłowe, serwer udostępni zasób. Jeżeli token jest niepoprawny, hasło się nie zgadza albo konto zostało zablokowane, ponowna próba również może zakończyć się kodem 401.

Sam kod błędu nie podaje pełnej przyczyny. Więcej informacji może znajdować się w treści odpowiedzi, konsoli przeglądarki, dokumentacji aplikacji albo w logach serwera.

Dlaczego pojawia się błąd 401?

Błąd 401 może wystąpić zarówno z powodu prostego problemu po stronie użytkownika, jak i nieprawidłowej konfiguracji strony. Do najczęstszych przyczyn należą:

• Nieprawidłowy login lub hasło. Użytkownik podaje błędne dane albo korzysta ze starego hasła zapisanego w przeglądarce.
• Brak danych uwierzytelniających. Aplikacja wysyła żądanie bez wymaganego tokenu, klucza API lub nagłówka Authorization.
• Wygaśnięcie sesji. Użytkownik był zalogowany, ale sesja zakończyła się po określonym czasie lub po zmianie hasła.
• Wygaśnięcie tokenu. Token dostępu stracił ważność, został unieważniony albo wystawiono go dla innej usługi.
• Uszkodzone lub nieaktualne pliki cookies. Przeglądarka przesyła dane sesji, których serwer już nie rozpoznaje.
• Zabezpieczenie katalogu hasłem. Dostęp do strony lub katalogu może być ograniczony przez konfigurację serwera i plik .htaccess.
• Konflikt wtyczki albo modułu bezpieczeństwa. Rozszerzenie może blokować prawidłowe logowanie lub żądania wysyłane do API.
• Nieprawidłowa konfiguracja serwera proxy, CDN lub zapory. Warstwa pośrednicząca może usuwać nagłówek uwierzytelniający albo odrzucać żądanie.
• Zablokowane konto. Dostęp może zostać czasowo ograniczony po wielu nieudanych próbach logowania.
• Błędny adres zasobu. Użytkownik może próbować otworzyć administracyjną lub prywatną wersję strony zamiast publicznego adresu.

W przypadku aplikacji korzystających z OAuth albo tokenów JWT częstą przyczyną jest brak wymaganego zakresu dostępu, niewłaściwy odbiorca tokenu, błędny podpis lub przekroczenie terminu ważności.

Czym różni się błąd 401 od błędu 403?

Kody 401 i 403 są często mylone, ponieważ oba mogą pojawić się podczas próby otwarcia chronionej strony. Opisują jednak inne sytuacje.

Przykładowo użytkownik próbujący otworzyć panel bez zalogowania może otrzymać 401. Po zalogowaniu serwer rozpoznaje jego konto. Jeżeli konto nie ma roli administratora, próba otwarcia ustawień administracyjnych może zakończyć się błędem 403.

Nie każda aplikacja stosuje te kody w identyczny sposób. Niektóre systemy zwracają 403 również w przypadku nieprawidłowego tokenu. Dlatego podczas diagnozy warto sprawdzić dokumentację konkretnej usługi i treść odpowiedzi serwera.

Jak naprawić błąd 401 jako użytkownik?

Jeżeli błąd pojawia się podczas korzystania ze strony, zacznij od prostych czynności. Nie wymagają one dostępu do serwera ani panelu administracyjnego.

1. Sprawdź adres strony. Upewnij się, że nie otwierasz starego linku, panelu administracyjnego lub prywatnego zasobu.
2. Odśwież stronę. Problem mógł być chwilowy, szczególnie jeśli sesja została właśnie odnowiona.
3. Zaloguj się ponownie. Wyloguj się, zamknij kartę, a następnie otwórz stronę i podaj aktualne dane.
4. Sprawdź dane logowania. Zwróć uwagę na wielkość liter, układ klawiatury i dane automatycznie uzupełniane przez menedżer haseł.
5. Otwórz stronę w trybie prywatnym. Pozwoli to sprawdzić, czy problem powodują zapisane pliki cookies lub rozszerzenia przeglądarki.
6. Usuń cookies dotyczące danej strony. Nie musisz od razu usuwać wszystkich danych zapisanych w przeglądarce.
7. Wyłącz tymczasowo rozszerzenia. Blokery reklam, narzędzia prywatności i rozszerzenia zabezpieczające mogą wpływać na proces logowania.
8. Skontaktuj się z administratorem. Podaj adres strony, godzinę wystąpienia błędu oraz czynność, którą wykonywałeś.

Nie przesyłaj administratorowi hasła ani pełnego tokenu dostępu. Do zgłoszenia wystarczy opis sytuacji, zrzut komunikatu oraz przybliżona godzina wystąpienia problemu.

Jak naprawić błąd 401 jako administrator strony?

Administrator powinien najpierw ustalić, która warstwa generuje odpowiedź. Kod może pochodzić z serwera WWW, systemu CMS, aplikacji, wtyczki zabezpieczającej, zapory, serwera proxy albo zewnętrznego API.

Przydatna kolejność diagnozy wygląda następująco:

1. Powtórz problem. Zapisz dokładny adres, metodę żądania, godzinę i warunki, w których występuje błąd.
2. Sprawdź odpowiedź HTTP. Otwórz narzędzia deweloperskie przeglądarki i przejdź do zakładki sieciowej. Poszukaj kodu 401 i nagłówka WWW-Authenticate.
3. Przeanalizuj logi. Porównaj wpisy w access logu, error logu i logach aplikacji zapisane w momencie wystąpienia błędu.
4. Zweryfikuj mechanizm logowania. Sprawdź ważność sesji, tokenu, klucza API oraz sposób przesyłania nagłówka Authorization.
5. Sprawdź konfigurację ochrony katalogów. Poszukaj reguł uwierzytelniania w konfiguracji serwera i pliku .htaccess.
6. Przetestuj warstwy pośredniczące. Upewnij się, że proxy, CDN i zapora aplikacyjna nie usuwają nagłówków potrzebnych do logowania.
7. Wyłączaj elementy pojedynczo. Jeśli podejrzewasz konflikt wtyczki lub modułu, wykonuj po jednej zmianie i po każdej ponawiaj test.
8. Przywróć poprawną konfigurację. Nie wyłączaj zabezpieczeń na stałe tylko po to, aby ukryć komunikat 401.

Na prawidłowo skonfigurowanym hostingu WWW administrator powinien mieć dostęp do narzędzi potrzebnych do zarządzania stroną i diagnozowania jej działania. W bardziej rozbudowanych środowiskach, takich jak serwery dedykowane, można również analizować logi systemowe, konfigurację usług oraz działanie serwerów pośredniczących.

Dobra praktyka. Jeżeli dane logowania, tokeny lub ciasteczka sesyjne są przesyłane przez internet, połączenie powinno być szyfrowane. Poprawnie wdrożony certyfikat SSL chroni transmisję między przeglądarką a serwerem, ale sam w sobie nie usuwa błędów w mechanizmie uwierzytelniania.

Przeczytaj wpis na naszym blogu i dowiedz się więcej o najpopularniejszych błędach serwera.