it-swarm.com.de

Was ist der richtige HTTP-Statuscode beim Umleiten auf eine Anmeldeseite?

Wenn ein Benutzer nicht angemeldet ist und versucht, auf eine Seite zuzugreifen, für die eine Anmeldung erforderlich ist, wie lautet der richtige HTTP-Statuscode für eine Umleitung zur Anmeldeseite?

Ich frage, weil keiner der vom W3C festgelegten xx-Antwortcodes scheinbar den Anforderungen entspricht:

10.3.1 300 Mehrfachauswahlmöglichkeiten

Die angeforderte Ressource entspricht einer von mehreren Repräsentationen, von denen jede ihren eigenen spezifischen Standort hat, und agentengesteuerte Verhandlungsinformationen (Abschnitt 12) werden bereitgestellt, damit der Benutzer (oder Benutzeragent) eine bevorzugte Repräsentation auswählen und seine umleiten kann Anfrage an diesen Ort.

Sofern es sich nicht um eine HEAD) - Anforderung handelte, MUSS die Antwort eine Entität mit einer Liste von Ressourcenmerkmalen und Speicherorten enthalten, aus der der Benutzer oder Benutzeragent die am besten geeignete auswählen kann wird durch den im Feld Inhaltstyp angegebenen Medientyp bestimmt. Dies hängt vom Format und den Funktionen von ab

im Benutzerprogramm kann die Auswahl der am besten geeigneten Option automatisch durchgeführt werden. Diese Spezifikation definiert jedoch keinen Standard für eine solche automatische Auswahl.

Wenn der Server eine bevorzugte Auswahl an Darstellungen hat, SOLLTE er den spezifischen URI für diese Darstellung in das Feld Standort aufnehmen. Benutzerprogramme KÖNNEN den Wert des Felds Standort für die automatische Umleitung verwenden. Diese Antwort kann zwischengespeichert werden, sofern nicht anders angegeben.

10.3.2 301 Permanent verschoben

Der angeforderten Ressource wurde eine neue permanente URI zugewiesen, und alle zukünftigen Verweise auf diese Ressource MÜSSEN eine der zurückgegebenen URIs verwenden. Clients mit Linkbearbeitungsfunktionen sollten Verweise auf den Request-URI nach Möglichkeit automatisch mit einem oder mehreren der vom Server zurückgegebenen neuen Verweise verknüpfen. Diese Antwort kann zwischengespeichert werden, sofern nicht anders angegeben.

Die neue permanente URI MUSS im Feld Ort in der Antwort angegeben werden. Sofern die Anforderungsmethode nicht HEAD war, MUSS die Entität der Antwort eine kurze Hypertextnotiz mit einem Hyperlink zu den neuen URIs enthalten.

Wenn der 301-Statuscode als Antwort auf eine andere Anforderung als GET oder HEAD empfangen wird, darf der Benutzeragent die Anforderung NICHT automatisch umleiten, es sei denn, dies kann vom Benutzer bestätigt werden, da dies die Bedingungen ändern kann, unter denen die Anforderung ausgestellt wurde.

  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 Gefunden

Die angeforderte Ressource befindet sich vorübergehend unter einem anderen URI. Da die Umleitung gelegentlich geändert werden kann, SOLLTE der Client den Request-URI für zukünftige Anforderungen weiterhin verwenden. Diese Antwort kann nur zwischengespeichert werden, wenn dies durch ein Cache-Control- oder Expires-Headerfeld angezeigt wird.

Der temporäre URI MUSS vom Feld Ort in der Antwort angegeben werden. Sofern die Anforderungsmethode nicht HEAD war, MUSS die Entität der Antwort eine kurze Hypertextnotiz mit einem Hyperlink zu den neuen URIs enthalten.

Wenn der 302-Statuscode als Antwort auf eine andere Anforderung als GET oder HEAD empfangen wird, DARF der Benutzeragent die Anforderung NICHT automatisch umleiten, es sei denn, er kann vom Benutzer bestätigt werden, da dies die Bedingungen ändern kann, unter denen die Anforderung ausgestellt wurde.

  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

bei einer Antwort von 303 wurde unabhängig von der ursprünglichen Anforderungsmethode ein GET für den Feldwert Location ausgeführt. Die Statuscodes 303 und 307 wurden für Server hinzugefügt, die eindeutig angeben möchten, welche Art von Reaktion vom Client erwartet wird.

10.3.4 303 Siehe Andere

Die Antwort auf die Anfrage finden Sie unter einem anderen URI und MÜSSEN mit einer GET-Methode für diese Ressource abgerufen werden. Diese Methode ist in erster Linie vorhanden, um die Ausgabe eines POST-aktivierten Skripts zu ermöglichen, um den Benutzeragenten zu einer ausgewählten Ressource umzuleiten. Der neue URI ist kein Ersatz für die ursprünglich angeforderte Ressource. Die 303-Antwort DARF NICHT zwischengespeichert werden, aber die Antwort auf die zweite (umgeleitete) Anforderung kann möglicherweise zwischengespeichert werden.

Die verschiedenen URI MÜSSEN durch das Feld Ort in der Antwort angegeben werden. Sofern die Anforderungsmethode nicht HEAD war, MUSS die Entität der Antwort eine kurze Hypertextnotiz mit einem Hyperlink zu den neuen URIs enthalten.

  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 Nicht geändert

Wenn der Client eine bedingte GET-Anforderung ausgeführt hat und der Zugriff zulässig ist, das Dokument jedoch nicht geändert wurde, MUSS der Server mit diesem Statuscode antworten. Die Antwort 304 DARF KEINEN Nachrichtentext enthalten und wird daher immer durch die erste leere Zeile nach den Kopfzeilenfeldern abgeschlossen.

Die Antwort MUSS die folgenden Headerfelder enthalten:

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

der taktlose Origin-Server befolgt diese Regeln, und Proxys und Clients fügen jeder Antwort, die ohne eine Antwort (wie bereits in [RFC 2068], Abschnitt 14.19 angegeben) eingeht, ihr eigenes Datum hinzu. Die Caches funktionieren dann ordnungsgemäß.

  - 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

abschnitt 13.3.3), die Antwort DARF KEINE anderen Entity-Header enthalten. Andernfalls (d. H. Das bedingte GET verwendet einen schwachen Prüfer) DARF die Antwort KEINE anderen Entitäts-Header enthalten; Dies verhindert Inkonsistenzen zwischen zwischengespeicherten Entitätskörpern und aktualisierten Kopfzeilen.

Wenn eine Antwort 304 angibt, dass eine Entität derzeit nicht zwischengespeichert ist, MUSS der Cache die Antwort ignorieren und die Anforderung ohne die Bedingung wiederholen.

Wenn ein Cache eine empfangene Antwort 304 verwendet, um einen Cache-Eintrag zu aktualisieren, MUSS der Cache den Eintrag aktualisieren, um alle in der Antwort angegebenen neuen Feldwerte widerzuspiegeln.

10.3.6 305 Proxy verwenden

Der Zugriff auf die angeforderte Ressource MUSS über den Proxy erfolgen, der im Feld Standort angegeben ist. Das Feld Location gibt den URI des Proxy an. Es wird erwartet, dass der Empfänger diese einzelne Anforderung über den Proxy wiederholt. 305 Antworten MÜSSEN nur von Origin-Servern generiert werden.

  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 (Unbenutzt)

Der Statuscode 306 wurde in einer früheren Version der Spezifikation verwendet, wird nicht mehr verwendet und der Code ist reserviert.

10.3.8 307 Temporäre Umleitung

Die angeforderte Ressource befindet sich vorübergehend unter einem anderen URI. Da die Umleitung gelegentlich geändert werden KANN, SOLLTE der Client die Anforderungs-URI für zukünftige Anforderungen weiterhin verwenden. Diese Antwort kann nur zwischengespeichert werden, wenn dies durch ein Cache-Control- oder Expires-Headerfeld angezeigt wird.

Der temporäre URI MUSS vom Feld Ort in der Antwort angegeben werden. Sofern die Anforderungsmethode nicht HEAD war, MUSS die Entität der Antwort eine kurze Hypertextnotiz mit einem Hyperlink zu den neuen URIs enthalten, da viele Benutzeragenten vor HTTP/1.1 den 307-Status nicht verstehen. Daher MUSS der Hinweis die Informationen enthalten, die ein Benutzer benötigt, um die ursprüngliche Anforderung für die neue URI zu wiederholen.

Wenn der Statuscode 307 als Antwort auf eine andere Anforderung als GET oder HEAD empfangen wird, DARF der Benutzeragent die Anforderung NICHT automatisch umleiten, es sei denn, er kann vom Benutzer bestätigt werden, da dies die Bedingungen ändern kann, unter denen die Anforderung ausgestellt wurde.

Ich benutze momentan 302, bis ich the die richtige Antwort finde.

Update & Fazit:

HTTP 302 ist besser, da bekannt ist, dass es die beste Kompatibilität mit Clients/Browsern aufweist.

117
Vidar Vestnes

Ich würde sagen 3 siehe andere 2 gefunden:

Die angeforderte Ressource befindet sich vorübergehend unter einem anderen URI. Da die Umleitung kann gelegentlich geändert werden, SOLLTE der Client den Request-URI für zukünftige Anfragen weiterhin verwenden. Diese Antwort kann nur zwischengespeichert werden, wenn dies durch ein Cache-Control- oder Expires-Headerfeld angezeigt wird.

passt meiner meinung nach am genauesten zu einer login seite. Ich dachte anfangs über 303 see other was genauso gut funktionieren würde. Nach einigem Nachdenken würde ich sagen 302 Found ist passender, da die angeforderte Ressource gefunden wurde . Es muss nur eine weitere Seite durchgesehen werden, bevor darauf zugegriffen werden kann. Die Antwort wird nicht standardmäßig zwischengespeichert, was ebenfalls in Ordnung ist.

57
Pekka 웃

Dies ist ein Missbrauch des HTTP-Umleitungsmechanismus. Wenn der Benutzer nicht autorisiert ist, muss Ihre App 401 Unauthorized. Falls der Benutzer berechtigt ist, aber keinen Zugriff auf die angeforderte Ressource hat, dann 403 Forbidden muss zurückgegeben werden.

Sie sollten die Umleitung auf Client-Seite durchführen, z. durch Javascript. Statuscode für die Umleitung, da die erforderliche Berechtigung nicht vorhanden ist . Die Verwendung von 30x entspricht nicht HTTP.

Wie man über HTTP-Statuscodes von Mark Nottingham nachdenkt

401 Unauthorized löst den HTTP-Anforderungsauthentifizierungsmechanismus aus.

401 Unauthorized Statuscode erfordert das Vorhandensein von WWW-Authenticate Header, der verschiedene Authentifizierungstypen unterstützt:

WWW-Authentifizierung: <Typ> Realm = <Realm>

Träger, OAuth, Basic, Digest, Cookie usw

45
filip26

Ich denke, die geeignete Lösung ist der HTTP 401-Header (nicht autorisiert).

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

Der Zweck dieses Headers ist genau dies. Anstatt auf eine Anmeldeseite umzuleiten, lautet der richtige Vorgang wie folgt:

  • Nicht angemeldete Benutzer versuchen, auf eine Seite mit Anmeldebeschränkungen zuzugreifen.
  • system identifiziert Benutzer ist nicht angemeldet
  • das System gibt den HTTP 401-Header zurück und zeigt das Anmeldeformular in derselben Antwort an (keine Umleitung).

Dies ist eine gute Vorgehensweise, beispielsweise das Bereitstellen einer nützlichen 404-Seite mit Sitemap-Links und einem Suchformular.

Wir sehen uns.

12
Dave