it-swarm.com.de

Soll ich einen http 401-Statuscode in einem HTML-basierten Anmeldeformular zurückgeben?

Soll ich einen http 401-Statuscode in einem HTML-basierten Anmeldeformular zurückgeben? Die Seite ist ein dediziertes Anmeldeformular und enthält keinen anderen aussagekräftigen Inhalt, nur das Site-Framework. Die URL kann sich jedoch auf eine Seite beziehen, die einen aussagekräftigen Inhalt hat, jedoch eine Anmeldung erfordert. Beachten Sie, dass dieses Setup nur den Statuscode 401 zurückgibt und den Benutzer nicht zur grundlegenden Authentifizierung auffordert.

In Bezug auf die Standards scheint es, dass 401 ein unangemessener Statuscode für HTML-basierte Anmeldeformulare ist. Ich habe jedoch noch nie erlebt oder von irgendwelchen negativen Konsequenzen gehört.

Beim Senden von 401 MUSS die Antwort ein WWW-Authenticate-Headerfeld (Abschnitt 14.47) enthalten, das eine für die angeforderte Ressource geltende Abfrage enthält.

anforderung hier erwähnt:

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

ausführlich hier:

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

Ich weiß, dass es Möglichkeiten gibt, Suchmaschinen zu umgehen, um sie davon zu überzeugen, Seiten basierend auf dem Vorhandensein eines Anmeldeformulars zu indizieren oder nicht, aber ich würde es vorziehen, http-Statuscodes zu verwenden, insbesondere 401, da die Definition wie a scheint perfekte Übereinstimmung, wenn nicht für die WWW-Authenticate-Header-Anforderung.

Gibt es einen Grund, warum ich 401 in diesem Fall nicht verwenden sollte? Gibt es semantisch einen Unterschied zwischen der Nichtautorisierung auf http-Ebene und der Autorisierung auf Anwendungsebene? Natürlich können Sie beides haben, aber ist die Authentifizierung auf http-Ebene nicht einfach, um sie nicht auf Anwendungsebene zu implementieren?

11
nosilleg

Wie Sie bemerken, erfordert RFC 2616 , dass eine 401-Antwort von einem RFC 2617 WWW-Authenticate-Header begleitet wird. Ich nehme an, Sie könnten diese Anforderung technisch erfüllen, indem Sie einen falschen Header wie den folgenden senden:

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

ich habe jedoch keine Ahnung, was Browser tun, wenn eine 401-Antwort angezeigt wird, die keine von ihnen verstandenen Herausforderungen enthält. Ich würde annehmen , dass die meisten, wenn nicht alle, dem Benutzer den Anforderungshauptteil präsentieren würden (wie RFC 2616 vorschreibt, sollten sie dies tun, wenn die Authentifizierung fehlschlägt), aber Keiner der RFCs scheint dies explizit zu sagen, daher wird möglicherweise stattdessen eine allgemeine Fehlermeldung angezeigt.

Eine mögliche Alternative (wenn Sie nicht wie alle anderen eine 200-Antwort verwenden möchten) wäre die Verwendung eines 403 Forbidden -Statuscodes. Dies ist ein weit verbreiteter Antwortcode, und meines Wissens sollten fast alle interaktiven Benutzeragenten (dh Browser im Gegensatz zu beispielsweise Suchmaschinen oder Download-Managern) darauf reagieren, indem sie dem Benutzer den Inhalt präsentieren. zumindest wenn es lang genug ist .

Obwohl die Beschreibung des 403-Statuscodes besagt, dass "[eine] Autorisierung nicht helfen wird", sollte dies im Zusammenhang mit der RFC 2617-Authentifizierung oder ähnlichen Autorisierungsmechanismen auf Protokollebene verstanden werden. Für den Browser ist nicht klar, ob das Senden eines Formulars und das Empfangen eines Cookies als Antwort als "Autorisierung" oder als etwas anderes gilt.

Ein häufiger verwendeter Mechanismus wäre, auf nicht authentifizierte Anforderungen mit einem temporäre Umleitung auf eine separate Anmeldeseite zu antworten, wobei die ursprüngliche URL als Parameter übergeben wird, damit der Benutzer nach erfolgreicher Authentifizierung zu dieser Seite zurückgeleitet werden kann . Beachten Sie jedoch, dass eine naive Implementierung es einer böswilligen Person ermöglichen kann, einen Anmeldelink zu erstellen, der den Benutzer nach dem Anmelden zu einer beliebigen URL umleitet. Wenn dies ein Sicherheitsproblem sein könnte, sollten Sie Maßnahmen ergreifen, um dies zu verhindern, z. indem Sie nur Rückgabe-URLs akzeptieren, die einem bekannten sicheren Muster entsprechen, oder indem Sie die Rückgabe-URL mit einem Nachrichtenauthentifizierungscode schützen, um Änderungen zu verhindern.

Wenn Sie nach der Anmeldung HTTP-Cookies zum Speichern von Authentifizierungstoken verwenden, sollten Sie in Ihren Antworten (vor und nach der Authentifizierung) einen Vary -Header einfügen, um ein unangemessenes Zwischenspeichern zu verhindern, wie in Vary: Cookie.

9
Ilmari Karonen

Erstens, wenn die Seite eine Anmeldung benötigt, sollten Sie sie wahrscheinlich durch robots.txt blockieren

Zweitens ist ein 401-Fehler korrekt, wenn Roboter die Seite erreichen.

2
Eric Yin

wahrscheinlich können Statuscodes für nicht-menschliche Benutzer nützlich sein [und für einige Browser? ]

unabhängig von der Anmeldemethode sollte der richtige Header gesendet werden

beispielsweise müssen Sie in Zukunft möglicherweise einen Wrapper-Client (keinen Webbrowser) schreiben, der sich lediglich durch die Anforderung der Seitenkopfzeilen authentifiziert und nicht die Gesamtheit des HTML-Codes

sie können Ihre Anmeldeanwendung mit beiden Methoden implementieren, indem Sie dieselbe Datenbank wie die Benutzerliste verwenden

0
user12370