401 vs 403: wybierz właściwy status dla odrzuconego żądania

401 vs 403

401 vs 403: Unauthorized czy Forbidden i który zwrócić | We.Inc

401 oznacza brak uwierzytelnienia, 403 oznacza uwierzytelnienie bez uprawnień. Odpowiedz na cztery pytania o żądanie i poznaj właściwy status wraz z nagłówkami i kodem.

Zwróć 401 Unauthorized, gdy żądanie nie ma ważnych danych uwierzytelniających: brak tokenu, wygasła sesja, zły podpis. Zalogowanie mogłoby to naprawić, a odpowiedź musi zawierać nagłówek WWW-Authenticate. Zwróć 403 Forbidden, gdy wiesz, kim jest wywołujący, a on i tak nie może tego zrobić, więc ponowne zalogowanie niczego nie zmieni.

Unauthorized kontra Forbidden

Odpowiedz na cztery pytania o żądanie, które odrzuca Twój serwer. Narzędzie podaje status do wysłania, nagłówek, który mu towarzyszy, oraz jednolinijkowe uzasadnienie do komentarza w kodzie. Obejmuje też przypadek, w którym wolisz nie przyznawać, że zasób istnieje.

Najczęściej zadawane pytania

Jaka jest główna różnica między 401 a 403?

401 mówi, że serwer nie wie, kim jesteś, albo nie przyjął przesłanego dowodu. 403 mówi, że wie, kim jesteś, a odpowiedź i tak brzmi nie.

Czy 401 musi zawierać nagłówek WWW-Authenticate?

Tak. RFC 9110 mówi, że serwer generujący odpowiedź 401 musi wysłać co najmniej jedno pole nagłówka WWW-Authenticate z challenge, na przykład Bearer dla API z tokenami.

Czy wygasły token powinien dostać 401 czy 403?

401. Dane uwierzytelniające nie są już ważne, a nowe by to naprawiły. Challenge Bearer może to zakomunikować przez error="invalid_token".

Czy mogę zwrócić 404 zamiast 403?

Tak. Specyfikacja pozwala serwerowi wysłać 404 zamiast 403, aby ukryć, czy zasób istnieje. To częsty wybór dla id należących do innych użytkowników.

Czy 403 oznacza, że mój adres IP jest zablokowany?

Może. Serwery wysyłają 403 przy każdej odmowie, którą uznają za ostateczną dla tego żądania: reguły IP, brak uprawnień do plików, reguła firewalla czy nieudane sprawdzenie roli. Treść odpowiedzi lub log serwera zwykle mówi, która to.

Dwa różne pytania

Co dodaje specyfikacja

Sprawdzenie w kodzie

Middleware Express: najpierw 401, potem 403

verifyToken zastępuje Twoje własne sprawdzenie sesji lub JWT. Kolejność ma znaczenie: najpierw uwierzytelnij, potem autoryzuj.

Frontend: reaguj inaczej na każdy z nich

Jedna ścieżka kodu wysyła użytkownika do logowania, druga wyjaśnia odmowę.

Jaki status powinienem zwrócić?

Tak

Nie

Czy żądanie zawierało dane uwierzytelniające (ciasteczko sesji, token, nagłówek Authorization)?

Czy te dane były ważne i nie wygasły?

Czy ten wywołujący może wykonać tę akcję na tym zasobie?

Czy wywołujący bez dostępu nie powinni się dowiedzieć, że zasób istnieje?

Wyślij to

Nikt nie jest zalogowany. Poproś o dane uwierzytelniające przez challenge.

Dane uwierzytelniające dotarły, ale zostały odrzucone. Nowe by to naprawiły.

Wywołujący jest znany i nie ma uprawnień. Ponowne zalogowanie nie pomoże.

Wywołujący nie ma uprawnień, a Ty wolisz nie ujawniać, że zasób istnieje.

Uwierzytelniony i uprawniony. Obsłuż żądanie.

Pominięte, bo wcześniejsza odpowiedź już przesądziła o statusie.

Zacznij za darmo · Bez karty kredytowej

Powiązane: Poradniki

Produkt

Dla kogo

Funkcje

Zasoby

Firma

Mapa strony