Welcher HTTP Status Code bei fehlender Berechtigung?

[lucid]

Hallo,

für einen Administrationsbereich ist eine Anmeldung des Benutzers erforderlich. Ist der Benutzer nicht angemeldet und versucht auf eine geschützte Ressource zuzugreifen, wird ein Formular angezeigt, in dem Benutzername und Kennwort abgefragt werden. Meldet der Benutzer sich an, wird (unter der selben URI wie zuvor das Formular) die geschützte Ressource ausgegeben (Status: 200 OK).

Nun stellt sich mir die Frage, welcher HTTP Status Code am besten für die Auslieferung des Formulars zur Anmeldung gewählt werden sollte.

403 Forbidden schien mir anfangs die richtige Wahl zu sein. In der HTTP Spezifikation [1] steht allerdings der folgende Satz:

"Authorization will not help and the request SHOULD NOT be repeated."

Ist hiermit jegliche Art von Autorisierung gemeint oder nur die HTTP-eigene Autorisierung und wäre es widersprüchlich nach der Anmeldung unter der selben URI die geschützten Inhalte auszuliefern, wenn die Anfrage doch nicht wiederholt werden soll?

Kann ich 403 Forbidden ohne Bedenken nutzen, oder gibt es einen anderen Status, der hier besser passt?

Gruß
lucid

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4

[Felix Riesterer]

Liebe(r) lucid,

Ist der Benutzer nicht angemeldet und versucht auf eine geschützte Ressource zuzugreifen, wird ein Formular angezeigt, in dem Benutzername und Kennwort abgefragt werden. [...]

Kann ich 403 Forbidden ohne Bedenken nutzen, oder gibt es einen anderen Status, der hier besser passt?

also ich könnte mir hier eher einen 401er vorstellen. Aber das übersteigt meine Erfahrungswerte. Frag lieber jemand anderen hier.

Ähm, ich glaube mit dem 401er kommt diese Browser-eigene Benutzer- und Passwortabfrage für HTTP-Authorisation. Das könnte absolut kontraproduktiv ausfallen. Vergiss es besser gleich wieder.

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[lucid]

Hallo Felix.

Ähm, ich glaube mit dem 401er kommt diese Browser-eigene Benutzer- und Passwortabfrage für HTTP-Authorisation. Das könnte absolut kontraproduktiv ausfallen. Vergiss es besser gleich wieder.

401 Unauthorized hatte ich auch gesehen, aber der scheint mir ausschließlich für die HTTP Authentication vorgesehen zu sein...

Aber trotzdem Danke für die Antwort. :-)

Gruß
lucid

[Johannes Zeller]

Hallo lucid,

401 Unauthorized hatte ich auch gesehen, aber der scheint mir ausschließlich für die HTTP Authentication vorgesehen zu sein...

Beide sind für die HTTP-Authentifizierung vorgesehen. Wenn du dies selber regelst, z.B. mit Sessions, verwende einfach wie bei anderen Seiten auch 200 OK.

Schöne Grüße,

Johannes

[wahsaga]

hi,

401 Unauthorized hatte ich auch gesehen, aber der scheint mir ausschließlich für die HTTP Authentication vorgesehen zu sein...

Beide sind für die HTTP-Authentifizierung vorgesehen.

Wenn du hier den 403 mit einbeziehst:
Den bekomme ich auch, wenn bspw. Verzeichnis-Listing deaktiviert ist - ohne dass HTTP Auth irgendwas damit zu tun hätte.

gruß,
wahsaga

[Johannes Zeller]

Hallo wahsaga,

Wenn du hier den 403 mit einbeziehst:
Den bekomme ich auch, wenn bspw. Verzeichnis-Listing deaktiviert ist - ohne dass HTTP Auth irgendwas damit zu tun hätte.

Ja, 403 Forbidden, bedeutet einfach nur, dass der Zugriff nicht erlaubt ist. Den kann man natürlich auch verwenden, wenn man die Zugriffsrechte nicht über HTTP regelt.

Schöne Grüße,

Johannes

[wahsaga]

hi,

Nun stellt sich mir die Frage, welcher HTTP Status Code am besten für die Auslieferung des Formulars zur Anmeldung gewählt werden sollte.

403 Forbidden schien mir anfangs die richtige Wahl zu sein. In der HTTP Spezifikation [1] steht allerdings der folgende Satz:

"Authorization will not help and the request SHOULD NOT be repeated."

Nun ja, _HTTP_ Authorization wird in deinem Szenario wirklich nicht helfen - es ist also unsinnig, den gleichen Request noch mal zu machen.
Wenn der Nutzer seine Login-Daten per Formular schickt, ist es aber nicht mehr der gleiche Request.

Aber "Authorization will not help" an sich ist ja schon widersprüchlich, bzw. geht an der Praxis vorbei.
Eine per HTTP Auth geschützte Ressource wird nach mehrmaligem Request mit den falschen Auth-Daten auch in aller Regel mit einem 403 quitiert; aber natürlich würde Authorization helfen - wenn sie denn nur endlich mal richtig wäre.

Ich halte das "and the request SHOULD NOT be repeated" eher für eine reine "Anweisung" auf HTTP-Ebene: Es ist sinnlos, dass der HTTP-Client den Request absolut identisch aus eigenem Ermessen erneut absetzt - anders, als bspw. bei einem 503, "Service [temporarily] Unavailable".
Wenn der Nutzer den Request aber erneut absetzt, nachdem er seine Login-Daten eingetippt hat - dann wäre das nach meinem Dafürhalten OK.

Kann ich 403 Forbidden ohne Bedenken nutzen,

Ganz ohne nicht, mit ein bisschen Bedenken aber m.E. Ja :-)

oder gibt es einen anderen Status, der hier besser passt?

402, "Payment Required"? *g*

Vielleicht noch ein 409, "Conflict":

"The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict."

current state - Nutzer leider nicht eingeloggt
user might be able to resolve the conflict - natürlich, muss sich ja nur einloggen
response body SHOULD include enough information for the user to recognize the source of the conflict - na die Info bekommt er, und ein "Werkzeug" zur Behebung des Konfliktes, das Formular, auch gleich dazu

Allerdings dürfe der 409 ein eher "exotischer" Response sein - müsste man erst mal rausfinden, wie die Browser mit dem umgehen.

In so fern stimme ich Johannes eigentlich zu - ein simpler 200er macht hier auch nix kaputt.

gruß,
wahsaga

[lucid]

Hallo wahsaga.

"Authorization will not help and the request SHOULD NOT be repeated."
[...]
Wenn der Nutzer seine Login-Daten per Formular schickt, ist es aber nicht mehr der gleiche Request.

Guter Punkt.

oder gibt es einen anderen Status, der hier besser passt?
[...]
Vielleicht noch ein 409, "Conflict":

Der scheint zwar auch relativ gut zu passen, ist aber leider schon zu speziell. Außerdem hat der Status der Benutzeranmeldung doch eigentlich nur entfernt (wenn überhaupt) mit dem Status der Ressource zu tun, oder?

In so fern stimme ich Johannes eigentlich zu - ein simpler 200er macht hier auch nix kaputt.

Kaputt macht er sicher nichts, nur schicke ich an der Stelle dann für ein und die selbe URI unterschiedliche Inhalte und das möchte ich vermeiden. Deshalb hätte ich gerne einen anderen Status als 200, um zu kennzeichnen, dass das Formular zur Anmeldung nicht der eigentliche Inhalt ist, sondern dass der ausgelieferte Inhalt auf die fehlende Berrechtigungen zurückzuführen ist.

Gruß
lucid

[wahsaga]

hi,

Vielleicht noch ein 409, "Conflict":

Der scheint zwar auch relativ gut zu passen, ist aber leider schon zu speziell.

In wie fern?

Außerdem hat der Status der Benutzeranmeldung doch eigentlich nur entfernt (wenn überhaupt) mit dem Status der Ressource zu tun, oder?

Ich sehe es so: Der aktuelle Status der Ressource ist "du kumms hier net rein" - eben _weil_ die Anmeldung noch nicht stattgefunden hat.

[...] nur schicke ich an der Stelle dann für ein und die selbe URI unterschiedliche Inhalte und das möchte ich vermeiden. Deshalb hätte ich gerne einen anderen Status als 200, um zu kennzeichnen, dass das Formular zur Anmeldung nicht der eigentliche Inhalt ist, sondern dass der ausgelieferte Inhalt auf die fehlende Berrechtigungen zurückzuführen ist.

Na ja, dann würde ich doch zum 403 tendieren.

gruß,
wahsaga

[lucid]

Hallo wahsaga.

Vielleicht noch ein 409, "Conflict":

Der scheint zwar auch relativ gut zu passen, ist aber leider schon zu speziell.

In wie fern?

Gemäß Spezifikation scheint der 409er vor allem für PUT Anfragen gedacht zu sein. Ist hierbei z. B. die Ressource, die geändert werden soll, bereits durch eine andere Anfrage gesperrt, erzeugt dies einen Konflikt.

Außerdem hat der Status der Benutzeranmeldung doch eigentlich nur entfernt (wenn überhaupt) mit dem Status der Ressource zu tun, oder?

Ich sehe es so: Der aktuelle Status der Ressource ist "du kumms hier net rein" - eben _weil_ die Anmeldung noch nicht stattgefunden hat.

Hmm, der Status der Ressource ist eigentlich immer der selbe. Der Status der Benutzeranmeldung (d. h. des Berechtigungsobjekts innerhalb der Session) hat hingegen jeweis unterschiedliche Werte. Und ansich greift die Berechtigungsprüfung ja auch schon weit bevor überhaupt auf die eigentliche Ressource zugegriffen bzw. diese erzeugt wird.

[...] nur schicke ich an der Stelle dann für ein und die selbe URI unterschiedliche Inhalte und das möchte ich vermeiden. Deshalb hätte ich gerne einen anderen Status als 200, um zu kennzeichnen, dass das Formular zur Anmeldung nicht der eigentliche Inhalt ist, sondern dass der ausgelieferte Inhalt auf die fehlende Berrechtigungen zurückzuführen ist.

Na ja, dann würde ich doch zum 403 tendieren.

Mittlerweile habe ich auch schon angedacht, das Anmeldungsformular unter einer eigenen URI zu hinterlegen und dann, im Falle fehlender Berechtigungen, mittels 302 auf das Formular umzuleiten. Das würde das Problem des doppelten Inhalts unter einer URI umgehen...

Gruß
lucid