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

Sollte 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, sondern nur das Site-Framework. Die URL kann sich jedoch auf eine Seite beziehen, die 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.

Wenn man sich die Standards ansieht, scheint 401 ein unangemessener Statuscode für HTML-basierte Anmeldeformulare zu sein. Ich habe jedoch noch nie irgendwelche negativen Konsequenzen davon erfahren oder 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 Herausforderung enthält."

hier genannte Anforderung:

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

detailliert hier:

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

Ich weiß, dass es Möglichkeiten gibt, wie ich Suchmaschinen umgehen kann, um sie davon zu überzeugen, Seiten basierend auf dem Vorhandensein eines Anmeldeformulars zu indizieren oder nicht, aber ich würde lieber http-Statuscodes verwenden, insbesondere 401, da die Definition wie a erscheint 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 nicht auf http-Ebene, nur um sie nicht auf Anwendungsebene zu implementieren?

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 gefälschten Header senden wie:

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

Ich habe jedoch keine Ahnung, was Browser tun werden, 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 sagt, sollten sie dies tun, wenn die Authentifizierung fehlschlägt), aber keiner der RFC scheint dies explizit zu sagen, sodass sie möglicherweise nur eine generische Fehlermeldung anzeigen stattdessen.

Eine mögliche Alternative (wenn Sie nicht einfach eine 200-Antwort verwenden möchten, wie es alle anderen zu tun scheinen) 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 den Inhalt zumindest dem Benutzer präsentieren wenn es lang genug ist .

Obwohl die Beschreibung des 403-Statuscodes besagt, dass "[a] Autorisierung nicht hilft", sollte dies IMO im Zusammenhang mit der RFC 2617-Authentifizierung oder ähnlichen Autorisierungsmechanismen auf Protokollebene verstanden werden. Was den Browser betrifft, hat er keine Ahnung, ob das Senden eines Formulars und das Empfangen eines Cookies als Antwort als "Autorisierung" oder etwas anderes gilt.

Ein häufiger verwendeter Mechanismus besteht darin, auf nicht authentifizierte Anforderungen mit einer temporären Umleitung auf eine separate Anmeldeseite zu antworten , wobei die ursprüngliche URL als Parameter übergeben wird, damit der Benutzer nach erfolgreicher Authentifizierung wieder dorthin umgeleitet 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. B. indem Sie nur akzeptieren Rückgabe-URLs, die einem bekannten sicheren Muster entsprechen, oder durch Schutz der Rückgabe-URL mit einem Nachrichtenauthentifizierungscode , um Änderungen zu verhindern.

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

Wenn sich die Seite anmelden muss, sollten Sie sie wahrscheinlich durch robots.txt blockieren

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

Wahrscheinlich können Statuscodes für Nicht-Menschen 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 nur durch Anfordern der Seitenkopfzeilen und nicht der Gesamtheit des HTML-Codes authentifiziert

Sie können Ihre Anmeldeanwendung mit beiden Methoden unter Verwendung derselben Datenbank wie die Benutzerliste implementieren