Czy powinienem zwrócić kod stanu HTTP 401 w formularzu logowania opartym na HTML?

Czy powinienem zwrócić kod stanu HTTP 401 w formularzu logowania opartym na HTML? Strona jest dedykowanym formularzem logowania i nie zawiera żadnych innych istotnych treści, a jedynie strukturę strony. Adres URL może jednak oznaczać stronę, która ma znaczącą treść, ale wymaga zalogowania. Należy pamiętać, że ta konfiguracja zwraca tylko kod stanu 401 i nie monituje użytkownika o podstawowe uwierzytelnienie.

Patrząc na standardy, wydaje się, że 401 jest nieodpowiednim kodem statusu dla formularzy logowania opartych na HTML. Jednak nigdy nie spotkałem się z żadnymi złymi konsekwencjami takiego postępowania.

Podczas wysyłania 401 „Odpowiedź MUSI zawierać pole nagłówka Uwierzytelnianie WWW (sekcja 14.47) zawierające wyzwanie mające zastosowanie do żądanego zasobu”.

wymóg wymieniony tutaj:

http://tools.ietf.org/html/rfc2616#section-10.4.2

szczegółowo tutaj:

http://tools.ietf.org/html/rfc2617#section-3.2.1

Wiem, że istnieją sposoby na obejście wyszukiwarek w celu przekonania ich do indeksowania stron, lub nie, na podstawie obecności formularza logowania, ale wolałbym używać kodów stanu HTTP, w szczególności 401, ponieważ jego definicja wydaje się być idealne dopasowanie, jeśli nie wymaga wymagania nagłówka Uwierzytelnianie WWW.

Czy jest jakiś powód, dla którego nie powinienem używać 401 w tym przypadku? Semantycznie czy jest jakaś różnica między brakiem autoryzacji na poziomie http a autoryzacją na poziomie aplikacji? Oczywiście możesz mieć jedno i drugie, ale czy uwierzytelnianie na poziomie http nie jest po prostu ze względu na łatwość niewprowadzania go na poziomie aplikacji?

Jak zauważasz, RFC 2616 wymaga, aby odpowiedzi 401 towarzyszył nagłówek RFC 2617 WWW-Authenticate. Przypuszczam, że technicznie możesz spełnić ten wymóg, wysyłając fałszywy nagłówek, taki jak:

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"

ale nie mam pojęcia, co zrobią przeglądarki, jeśli otrzyma odpowiedź 401, która nie zawiera zrozumiałych wyzwań. Chciałbym założyć, że większość, jeśli nie wszystkie z nich prezentujemy ciało zapytanie do użytkownika (jako RFC 2616 mówi powinni zrobić, jeśli uwierzytelnianie nie powiedzie się), ale nie RFC zdaje się mówić tak wyraźnie, więc mogą oni legalnie prostu pokazać ogólny komunikat o błędzie zamiast.

Możliwą alternatywą (jeśli nie chcesz po prostu użyć odpowiedzi 200, jak wszyscy inni zdają się robić), byłoby użyć kodu statusu 403 Forbidden . Jest to powszechnie stosowany kod odpowiedzi i o ile mi wiadomo, prawie wszystkie interaktywne programy użytkownika (tj. Przeglądarki, w przeciwieństwie do, powiedzmy, wyszukiwarek lub menedżerów pobierania), powinny zareagować na to, przedstawiając treść przynajmniej użytkownikowi jeśli to wystarczająco długo .

Chociaż w opisie kodu stanu 403 jest napisane, że „automatyzacja nie pomoże”, IMO powinno to być rozumiane w kontekście jako odnoszące się do uwierzytelnienia RFC 2617 lub podobnych mechanizmów autoryzacji na poziomie protokołu; jeśli chodzi o przeglądarkę, nie ma pojęcia, czy przesłanie formularza i otrzymanie pliku cookie w odpowiedzi liczy się jako „autoryzacja” czy coś innego.

Jednym z częściej używanych mechanizmów byłoby odpowiadanie na nieuwierzytelnione żądania za pomocą tymczasowego przekierowania na osobną stronę logowania, przy czym oryginalny adres URL był przekazywany jako parametr, aby użytkownik mógł zostać przekierowany z powrotem do niego po udanym uwierzytelnieniu. Pamiętaj jednak, że naiwna implementacja może pozwolić złośliwej osobie na utworzenie linku logowania, który przekierowałby użytkownika na dowolny adres URL po zalogowaniu. Jeśli może to być problem z bezpieczeństwem, powinieneś podjąć kroki, aby temu zapobiec, np. Akceptując tylko zwracają adresy URL pasujące do znanego bezpiecznego wzorca lub chronią zwrotny adres URL kodem uwierzytelniającym wiadomość, aby zapobiec modyfikacji.

W każdym razie, jeśli używasz plików cookie HTTP do przechowywania tokenów uwierzytelniających po zalogowaniu, powinieneś dołączyć nagłówek Vary w swoich odpowiedziach (zarówno przed, jak i po uwierzytelnieniu), aby zapobiec niewłaściwemu buforowaniu, jak w Vary: Cookie.

Po pierwsze, jeśli strona wymaga logowania, prawdopodobnie powinieneś ją zablokować przez robots.txt

Po drugie, jeśli roboty dotrą do strony, błąd 401 jest poprawny.

prawdopodobnie kody statusu mogą być przydatne dla osób innych niż ludzie [i niektórych przeglądarek? ]

niezależnie od metody logowania, należy wysłać poprawny nagłówek

na przykład w przyszłości może być konieczne napisanie klienta opakowania (a nie przeglądarki internetowej), który po prostu się uwierzytelni, żądając nagłówków stron, a nie całego kodu HTML

możesz zaimplementować aplikację logowania przy użyciu obu metod, korzystając z tej samej bazy danych, co lista użytkowników