Jaki jest prawidłowy kod stanu HTTP podczas przekierowywania do strony logowania?

Kiedy użytkownik nie jest zalogowany i próbuje uzyskać dostęp do strony wymagającej logowania, jaki jest poprawny kod stanu HTTP dla przekierowania do strony logowania?

Pytam, ponieważ żaden z kodów odpowiedzi 3xx określonych przez W3C nie wydaje się spełniać wymagań:

10.3.1 300 wielokrotnych wyborów

Żądany zasób odpowiada dowolnemu z zestawu reprezentacji, z których każda ma swoją własną, określoną lokalizację, i dostarczane są informacje negocjacyjne oparte na agentach (sekcja 12), aby użytkownik (lub agent użytkownika) mógł wybrać preferowaną reprezentację i przekierować jej żądanie do tej lokalizacji.

O ile nie było to żądanie HEAD, odpowiedź POWINNA zawierać encję zawierającą listę charakterystyk zasobów i lokalizacji, z których użytkownik lub agent użytkownika może wybrać najbardziej odpowiednią. Format jednostki jest określony przez typ nośnika podany w polu nagłówka Content-Type. W zależności od formatu i możliwości

agent użytkownika, wybór najwłaściwszego wyboru MOŻE być wykonany automatycznie. Jednak ta specyfikacja nie definiuje żadnego standardu takiego automatycznego wyboru.

Jeśli serwer ma preferowany wybór reprezentacji, POWINIEN dołączyć określony identyfikator URI dla tej reprezentacji w polu Lokalizacja; agenty użytkownika MOGĄ używać wartości pola Lokalizacja do automatycznego przekierowania. Ta odpowiedź może być buforowana, chyba że wskazano inaczej.

10.3.2 301 Przeniesiono na stałe

Do żądanego zasobu został przypisany nowy stały identyfikator URI, a wszelkie przyszłe odwołania do tego zasobu POWINNY używać jednego ze zwróconych identyfikatorów URI. Klienci z możliwością edycji linków powinni automatycznie ponownie łączyć odniesienia do URI żądania z jednym lub większą liczbą nowych odniesień zwróconych przez serwer, jeśli to możliwe. Ta odpowiedź może być buforowana, chyba że wskazano inaczej.

Nowy stały URI POWINIEN być podany w polu Location odpowiedzi. O ile metoda żądania nie była HEAD, jednostka odpowiedzi POWINNA zawierać krótką notatkę hipertekstową z hiperłączem do nowych identyfikatorów URI.

Jeśli kod stanu 301 zostanie odebrany w odpowiedzi na żądanie inne niż GET lub HEAD, agent użytkownika NIE MOŻE automatycznie przekierowywać żądania, chyba że zostanie to potwierdzone przez użytkownika, ponieważ może to zmienić warunki, na jakich żądanie zostało wysłane.

  Note: When automatically redirecting a POST request after
  receiving a 301 status code, some existing HTTP/1.0 user agents
  will erroneously change it into a GET request.

10.3.3 302 Znaleziono

Żądany zasób znajduje się tymczasowo pod innym identyfikatorem URI. Ponieważ przekierowanie może być czasami zmieniane, klient POWINIEN nadal używać identyfikatora URI żądania dla przyszłych żądań. Ta odpowiedź może zostać zapisana w pamięci podręcznej tylko wtedy, gdy jest to wskazane w polu nagłówka Cache-Control lub Expires.

Tymczasowy URI POWINIEN być podany w polu Location odpowiedzi. O ile metoda żądania nie była HEAD, jednostka odpowiedzi POWINNA zawierać krótką notatkę hipertekstową z hiperłączem do nowych URI.

Jeśli kod statusu 302 zostanie odebrany w odpowiedzi na żądanie inne niż GET lub HEAD, agent użytkownika NIE MOŻE automatycznie przekierowywać żądania, chyba że zostanie to potwierdzone przez użytkownika, ponieważ może to zmienić warunki, na jakich żądanie zostało wysłane.

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it

były odpowiedzią 303, wykonując GET na wartości pola Lokalizacja niezależnie od pierwotnej metody żądania. Kody statusu 303 i 307 zostały dodane dla serwerów, które chcą jednoznacznie wyjaśnić, jakiego rodzaju reakcji oczekuje się od klienta.

10.3.4 303 Zobacz inne

Odpowiedź na żądanie można znaleźć pod innym identyfikatorem URI i POWINNA zostać pobrana przy użyciu metody GET na tym zasobie. Ta metoda istnieje głównie po to, aby dane wyjściowe skryptu aktywowanego metodą POST przekierowywały agenta użytkownika do wybranego zasobu. Nowy identyfikator URI nie jest zastępczym odwołaniem do pierwotnie żądanego zasobu. Odpowiedź 303 NIE MOŻE być buforowana, ale odpowiedź na drugie (przekierowane) żądanie może być buforowana.

W polu Lokalizacja w odpowiedzi NALEŻY podać inny identyfikator URI. O ile metoda żądania nie była HEAD, jednostka odpowiedzi POWINNA zawierać krótką notatkę hipertekstową z hiperłączem do nowych identyfikatorów URI.

  Note: Many pre-HTTP/1.1 user agents do not understand the 303
  status. When interoperability with such clients is a concern, the
  302 status code may be used instead, since most user agents react
  to a 302 response as described here for 303.

10.3.5 304 Nie zmodyfikowano

Jeśli klient wykonał warunkowe żądanie GET i dostęp jest dozwolony, ale dokument nie został zmodyfikowany, serwer POWINIEN odpowiedzieć tym kodem stanu. Odpowiedź 304 NIE MOŻE zawierać treści wiadomości i dlatego jest zawsze zakończona pierwszą pustą linią po polach nagłówka.

Odpowiedź MUSI zawierać następujące pola nagłówka:

  - Date, unless its omission is required by section 14.18.1 If a

Bez zegara serwer pochodzenia przestrzega tych reguł, a serwery proxy i klienci dodają własną datę do każdej odpowiedzi otrzymanej bez niej (jak już określono w [RFC 2068], sekcja 14.19), pamięci podręczne będą działać poprawnie.

  - ETag and/or Content-Location, if the header would have been sent
    in a 200 response to the same request
  - Expires, Cache-Control, and/or Vary, if the field-value might
    differ from that sent in any previous response for the same
    variant If the conditional GET used a strong cache validator (see

sekcja 13.3.3), odpowiedź NIE POWINNA zawierać innych nagłówków encji. W przeciwnym razie (tj. Warunkowe GET użyło słabego walidatora), odpowiedź NIE MOŻE zawierać innych nagłówków encji; zapobiega to niespójnościom między treściami jednostek zapisanymi w pamięci podręcznej a zaktualizowanymi nagłówkami.

Jeśli odpowiedź 304 wskazuje, że jednostka nie jest obecnie buforowana, pamięć podręczna MUSI zignorować odpowiedź i powtórzyć żądanie bez warunku.

Jeżeli pamięć podręczna używa odebranej odpowiedzi 304 do aktualizacji wpisu pamięci podręcznej, pamięć podręczna MUSI zaktualizować wpis, aby odzwierciedlić nowe wartości pól podane w odpowiedzi.

10.3.6 305 Użyj proxy

Żądany zasób MUSI być dostępny przez proxy podane w polu Lokalizacja. Pole Location zawiera identyfikator URI proxy. Odbiorca powinien powtórzyć to pojedyncze żądanie za pośrednictwem serwera proxy. 305 odpowiedzi MUSZĄ być generowane tylko przez serwery pochodzenia.

  Note: RFC 2068 was not clear that 305 was intended to redirect a
  single request, and to be generated by origin servers only.  Not
  observing these limitations has significant security consequences.

10.3.7 306 (nieużywany)

Kod stanu 306 był używany w poprzedniej wersji specyfikacji, nie jest już używany, a kod jest zarezerwowany.

10.3.8 307 Tymczasowe przekierowanie

Żądany zasób znajduje się tymczasowo pod innym identyfikatorem URI. Ponieważ przekierowanie MOŻE być czasami zmieniane, klient POWINIEN nadal używać Request-URI dla przyszłych żądań. Ta odpowiedź może zostać zapisana w pamięci podręcznej tylko wtedy, gdy jest to wskazane w polu nagłówka Cache-Control lub Expires.

Tymczasowy URI POWINIEN być podany w polu Location odpowiedzi. O ile metoda żądania nie była HEAD, jednostka odpowiedzi POWINNA zawierać krótką notatkę hipertekstową z hiperłączem do nowych identyfikatorów URI, ponieważ wielu klientów użytkowników sprzed HTTP / 1.1 nie rozumie statusu 307. Dlatego notatka POWINNA zawierać informacje niezbędne użytkownikowi do powtórzenia pierwotnego żądania dotyczącego nowego identyfikatora URI.

Jeśli kod statusu 307 zostanie odebrany w odpowiedzi na żądanie inne niż GET lub HEAD, agent użytkownika NIE MOŻE automatycznie przekierowywać żądania, chyba że zostanie to potwierdzone przez użytkownika, ponieważ może to zmienić warunki, na jakich żądanie zostało wysłane.

Używam 302 do teraz, aż znajdę się poprawną odpowiedź.

Aktualizacja i wnioski:

HTTP 302 jest lepszy, ponieważ wiadomo, że ma najlepszą zgodność z klientami / przeglądarkami.

Powiedziałbym, że 303 zobacz inne 302 Znalezione:

Żądany zasób znajduje się tymczasowo pod innym identyfikatorem URI. Ponieważ przekierowanie może być czasami zmieniane , klient POWINIEN nadal używać identyfikatora URI żądania dla przyszłych żądań. Ta odpowiedź może być zapisywana w pamięci podręcznej tylko wtedy, gdy jest to wskazane w polu nagłówka Cache-Control lub Expires.

Moim zdaniem najbardziej pasuje do strony logowania. Początkowo zastanawiałem się, 303 see otherktóre będzie działać równie dobrze. Po namyśle powiedziałbym, że 302 Foundjest bardziej odpowiedni, ponieważ żądany zasób został znaleziony, wystarczy przejść przez kolejną stronę, zanim będzie można uzyskać do niego dostęp. Odpowiedź nie jest domyślnie zapisywana w pamięci podręcznej, co również jest w porządku.

Jest to nadużycie mechanizmu przekierowania HTTP. Jeśli użytkownik nie jest autoryzowany, Twoja aplikacja musi wrócić 401 Unauthorized. W przypadku, gdy użytkownik jest autoryzowany, ale nie ma dostępu do żądanego zasobu, 403 Forbiddennależy go zwrócić.

Powinieneś zrobić to przekierowanie po stronie klienta, np. Przez javascript. kod statusu przekierowania, ponieważ nie istnieje wymagana autoryzacja . Używanie 30x do tego nie jest zgodne z HTTP.

Jak myśleć o kodach stanu HTTP autorstwa Marka Nottinghama

401 Unauthorized uruchamia mechanizm uwierzytelniania żądań HTTP.

401 Unauthorizedkod statusu wymaga obecności WWW-Authenticatenagłówka obsługującego różne typy uwierzytelniania:

WWW-Authenticate: <type> realm = <realm>

Bearer, OAuth, Basic, Digest, Cookie itp

• Rejestr schematu uwierzytelniania Hypertext Transfer Protocol (HTTP)
• Uwierzytelnianie HTTP oparte na plikach cookie - WERSJA ROBOCZA

Myślę, że odpowiednim rozwiązaniem jest nagłówek HTTP 401 (Not Authorized).

http://en.wikipedia.org/wiki/HTTP_codes#4xx_Client_Error

Celem tego nagłówka jest właśnie to. Ale zamiast przekierowywać na stronę logowania, prawidłowy proces wyglądałby tak:

• Niezalogowany użytkownik próbuje uzyskać dostęp do strony z ograniczeniami logowania.
• system wskazuje, że użytkownik nie jest zalogowany
• system zwraca nagłówek HTTP 401 ORAZ wyświetla formularz logowania w tej samej odpowiedzi (nie przekierowaniu).

Jest to dobra praktyka, np. Zapewnienie użytecznej strony 404 z linkami do mapy witryny i formularzem wyszukiwania.

Do zobaczenia.