it-swarm.com.de

403 Verbotene vs 401 Nicht autorisierte HTTP-Antworten

Für eine vorhandene Webseite, für die jedoch ein Benutzer mit nicht ausreichenden Berechtigungen (der nicht angemeldet ist oder nicht zur richtigen Benutzergruppe gehört), welche HTTP-Antwort muss bereitgestellt werden? 401? 403? Etwas anderes? Was ich bisher jeweils gelesen habe, ist in Bezug auf den Unterschied zwischen den beiden nicht sehr klar. Welche Anwendungsfälle sind für jede Antwort geeignet?

2411
VirtuosiMedia

Eine klare Erklärung von Daniel Irvine :

Es gibt ein Problem mit 401 Unauthorized , dem HTTP-Statuscode für Authentifizierungsfehler. Und das ist genau das Richtige: Es dient der Authentifizierung und nicht der Autorisierung. Beim Empfang einer 401-Antwort teilt Ihnen der Server mit: „Sie sind nicht authentifiziert - entweder gar nicht oder falsch authentifiziert -, aber bitte authentifizieren Sie sich erneut und versuchen Sie es erneut.“ Als Hilfe wird immer ein WWW-Authenticate Header, der die Authentifizierung beschreibt.

Dies ist eine Antwort, die im Allgemeinen von Ihrem Webserver und nicht von Ihrer Webanwendung zurückgegeben wird.

Es ist auch etwas sehr Vorübergehendes. Der Server fordert Sie auf, es erneut zu versuchen.

Für die Autorisierung verwende ich die Antwort 403 Forbidden . Es ist permanent, es ist an meine Anwendungslogik gebunden und es ist eine konkretere Antwort als ein 401.

Der Server, der eine 403-Antwort erhält, teilt Ihnen mit: "Es tut mir leid. Ich weiß, wer Sie sind - ich glaube, wer Sie sind -, aber Sie haben keine Berechtigung, auf diese Ressource zuzugreifen. Wenn Sie den Systemadministrator freundlich fragen, erhalten Sie möglicherweise eine Erlaubnis. Aber bitte störe mich nicht noch einmal, bis sich deine Lage ändert. "

Zusammenfassend sollte eine 401 nicht autorisierte Antwort für fehlende oder fehlerhafte Authentifizierung verwendet werden, und eine 403 verbotene Die Antwort sollte anschließend verwendet werden, wenn der Benutzer authentifiziert ist, aber nicht berechtigt ist, die angeforderte Operation für die angegebene Ressource auszuführen.

Ein weiteres schönes Bildformat wie http-Statuscodes verwendet werden sollen.

enter image description here

3607
JPReddy

Siehe RFC2616 :

401 nicht Autorisiert:

Wenn die Anforderung bereits Berechtigungsnachweise enthielt, zeigt die Antwort 401 an, dass die Berechtigung für diese Berechtigungsnachweise verweigert wurde.

403 Verboten:

Der Server hat die Anfrage verstanden, lehnt sie jedoch ab.

Update

Aus Ihrem Anwendungsfall geht hervor, dass der Benutzer nicht authentifiziert ist. Ich würde 401 zurückgeben.


Bearbeiten: RFC2616 ist veraltet, siehe RFC7231 und RFC7235 .

370
Oded

Die anderen Antworten fehlen. Es muss verstanden werden, dass sich Authentifizierung und Autorisierung im Kontext von RFC 2616 NUR auf das HTTP-Authentifizierungsprotokoll von RFC 2617 bezieht. Die Authentifizierung durch Schemata außerhalb von RFC 2617 wird in HTTP-Statuscodes nicht unterstützt und nicht berücksichtigt bei der Entscheidung, ob 401 oder 403 verwendet werden soll.

Kurz und knapp

Nicht autorisiert zeigt an, dass der Client nicht RFC2617-authentifiziert ist und der Server den Authentifizierungsprozess initiiert. Verboten zeigt an, dass der Client RFC2617-authentifiziert ist und keine Berechtigung besitzt oder dass der Server RFC2617 für die angeforderte Ressource nicht unterstützt.

Das heißt, wenn Sie einen eigenen Anmeldeprozess haben und niemals die HTTP-Authentifizierung verwenden, ist 403 immer die richtige Antwort und 401 sollte niemals verwendet werden.

Detailliert und ausführlich

Aus RFC2616

10.4.2 401 Nicht autorisiert

Die Anforderung erfordert eine Benutzerauthentifizierung. Die Antwort MUSS ein WWW-Authenticate-Headerfeld (Abschnitt 14.47) enthalten, das eine für die angeforderte Ressource geltende Abfrage enthält. Der Kunde KANN die Anfrage mit einem geeigneten Authorization-Header-Feld wiederholen (Abschnitt 14.8).

und

10.4.4 403 Verboten Der Server hat die Anfrage verstanden, lehnt sie jedoch ab. Die Autorisierung hilft nicht und die Anfrage SOLLTE NICHT wiederholt werden.

Als Erstes ist zu beachten, dass sich "Authentifizierung" und "Autorisierung" im Kontext dieses Dokuments speziell auf die HTTP-Authentifizierungsprotokolle von RFC 2617 beziehen. Sie beziehen sich nicht auf selbst erstellte Authentifizierungsprotokolle Verwenden von Anmeldeseiten usw. Ich verwende "login", um auf die Authentifizierung und Autorisierung durch andere Methoden als RFC2617 zu verweisen

Der wirkliche Unterschied besteht also nicht darin, wo das Problem liegt oder ob es eine Lösung gibt. Der Unterschied besteht darin, was der Server als Nächstes vom Client erwartet.

401 gibt an, dass die Ressource nicht bereitgestellt werden kann, der Server jedoch ANFORDERT, dass sich der Client über die HTTP-Authentifizierung anmeldet und Antwortheader gesendet hat, um den Prozess zu initiieren. Möglicherweise gibt es Berechtigungen, die den Zugriff auf die Ressource ermöglichen, möglicherweise jedoch nicht. Probieren Sie es aus und sehen Sie, was passiert.

403 gibt an, dass die Ressource nicht bereitgestellt werden kann, und es gibt für den aktuellen Benutzer keine Möglichkeit, dies über RFC2617 zu lösen, und es macht keinen Sinn, es zu versuchen. Dies kann daran liegen, dass bekanntermaßen keine Authentifizierungsebene ausreicht (z. B. aufgrund einer IP-Sperrliste), der Benutzer jedoch bereits authentifiziert ist und keine Berechtigung besitzt. Das RFC2617-Modell besteht aus einem Benutzer und einem Berechtigungsnachweis, sodass der Fall, in dem der Benutzer möglicherweise über einen zweiten Satz von Berechtigungsnachweisen verfügt, möglicherweise ignoriert wird. Es wird weder vorgeschlagen noch impliziert, dass eine Art Anmeldeseite oder ein anderes Nicht-RFC2617-Authentifizierungsprotokoll möglicherweise Abhilfe schafft oder nicht - dies liegt außerhalb der RFC2616-Standards und -Definitionen.


Bearbeiten: RFC2616 ist veraltet, siehe RFC7231 und RFC7235 .

284
ldrut
 Ressource vorhanden? 
 | | 
 NO | | JA 
 V v 
 404 Ist angemeldet (authentifiziert)? 
 Oder | | 
 401 NO | | JA 
 403 | | 
 v v 
 401 Kann auf Ressourcen zugreifen, Berechtigungen (autorisiert)? 
 (404 nicht offengelegt) | | 
 oder 301 NO | | JA 
 Umleiten | | 
 zum Anmelden v v 
 403 OK 200, 301, ... 
 (oder 404: keine Offenbarung) 
 

Überprüfungen werden normalerweise in dieser Reihenfolge durchgeführt:

  • 401 wenn nicht angemeldet oder Sitzung abgelaufen
  • 403, wenn der Benutzer keine Berechtigung zum Zugriff auf die Ressource hat (Datei, JSON, ...)
  • 404 wenn die Ressource nicht existiert (oder nicht bereit ist, etwas preiszugeben)

UNAUTHORIZED: Statuscode (401), der angibt, dass für die Anforderung Authentifizierung erforderlich ist. Dies bedeutet normalerweise, dass der Benutzer angemeldet sein muss (Sitzung). Dem Server unbekannter Benutzer/Agent. Kann mit anderen Anmeldeinformationen wiederholen. HINWEIS: Dies ist verwirrend, da der Name "nicht authentifiziert" anstelle von "nicht autorisiert" lauten sollte. Dies kann auch nach der Anmeldung geschehen, wenn die Sitzung abgelaufen ist. Sonderfall: Kann anstelle von 404 verwendet werden, um das Vorhandensein oder Nichtvorhandensein von Ressourcen zu vermeiden (credits @gingerCodeNinja)

FORBIDDEN: Statuscode (403), der angibt, dass der Server die Anforderung verstanden hat, sie jedoch nicht erfüllt hat. Benutzer/Agent, der dem Server bekannt ist, jedoch nzureichende Anmeldeinformationen. Wiederholte Anforderungen funktionieren nur, wenn die Anmeldeinformationen geändert wurden. Dies ist in kurzer Zeit sehr unwahrscheinlich. Sonderfall: Kann anstelle von 404 verwendet werden, um das Vorhandensein oder Nichtvorhandensein von Ressourcen zu vermeiden (credits @gingerCodeNinja)

NOT FOUND: Statuscode (404) zeigt an, dass die angeforderte Ressource nicht verfügbar ist. Benutzer/Agent bekannt, Server gibt jedoch nichts über die Ressource preis und tut so, als ob sie nicht existiert. Wiederholen funktioniert nicht. Dies ist eine spezielle Verwendung von 404 (Github macht es zum Beispiel).

112

Gemäß RFC 2616 (HTTP/1.1) wird 403 gesendet, wenn:

Der Server hat die Anfrage verstanden, lehnt sie jedoch ab. Die Autorisierung hilft nicht und die Anfrage SOLLTE NICHT wiederholt werden. Wenn die Anforderungsmethode nicht HEAD war und der Server veröffentlichen möchte, warum die Anforderung nicht erfüllt wurde, SOLLTE er den Grund für die Ablehnung in der Entität beschreiben. Wenn der Server diese Informationen dem Client nicht zur Verfügung stellen möchte, kann stattdessen der Statuscode 404 (Not Found) verwendet werden

Mit anderen Worten, wenn der Client durch Authentifizierung Zugriff auf die Ressource erhält, sollte 401 gesendet werden.

108
Cumbayah

Annahme der HTTP-Authentifizierung ( WWW-Authentifizierung und Autorisierung headers) wird verwendet . Wenn die Authentifizierung als ein anderer Benutzer Zugriff auf die angeforderte Ressource gewähren würde, sollte 401 Unauthorized zurückgegeben werden.

403 Verboten wird verwendet, wenn der Zugriff auf die Ressource für alle Personen verboten oder auf ein bestimmtes Netzwerk beschränkt ist oder nur über SSL zulässig ist, unabhängig davon, ob es sich um eine HTTP-Authentifizierung handelt.

Wenn die HTTP-Authentifizierung nicht verwendet wird und der Dienst ein Cookie-basiertes Authentifizierungsschema verwendet, wie es heutzutage üblich ist, sollte ein 403 oder ein 404 zurückgegeben werden.

In Bezug auf 401 stammt dies aus RFC 7235 (Hypertext Transfer Protocol (HTTP/1.1): Authentifizierung):

3.1. 401 nicht Autorisiert

Der 401-Statuscode (Nicht autorisiert) gibt an, dass die Anforderung nicht angewendet wurde, da gültige Authentifizierungsinformationen für die Zielressource fehlen. Der Origin-Server MUSS ein WWW-Authenticate-Header-Feld (Abschnitt 4.4) senden, das mindestens eine für die Zielressource geltende Abfrage enthält. Wenn die Anforderung Authentifizierungsinformationen enthielt, zeigt die Antwort 401 an, dass die Autorisierung für diese Informationen verweigert wurde . Der Kunde KANN die Anfrage mit einem neuen oder ersetzten Feld für den Autorisierungskopf wiederholen (Abschnitt 4.1). Wenn die Antwort 401 die gleiche Herausforderung wie die vorherige Antwort enthält und der Benutzeragent bereits mindestens einmal versucht hat, sich zu authentifizieren, MUSS der Benutzeragent dem Benutzer die beigefügte Darstellung vorlegen, da sie normalerweise relevante Diagnoseinformationen enthält.

Die Semantik von 403 (und 404) hat sich im Laufe der Zeit geändert. Dies ist aus dem Jahr 1999 (RFC 2616):

10.4.4 403 Verboten

Der Server hat die Anfrage verstanden, lehnt sie jedoch ab.
Die Autorisierung hilft nicht und die Anfrage SOLLTE NICHT wiederholt werden.
Wenn die Anforderungsmethode nicht HEAD war und der Server dies wünscht
öffentlich, warum die Anfrage nicht erfüllt wurde, sollte der Grund für die Ablehnung in der Entität beschrieben werden. Wenn der Server diese Informationen dem Client nicht zur Verfügung stellen möchte, den Statuscode 404
(Nicht gefunden) kann stattdessen verwendet werden.

Im Jahr 2014 hat RFC 7231 (Hypertext Transfer Protocol (HTTP/1.1): Semantik und Inhalt) die Bedeutung von 403 geändert:

6.5.3. 403 Verboten

Der Statuscode 403 (Verboten) gibt an, dass der Server die Anforderung verstanden hat, sie jedoch nicht autorisiert. Ein Server, der veröffentlichen möchte, warum die Anforderung verboten wurde, kann diesen Grund in der Antwortnutzlast (falls vorhanden) beschreiben.

Wenn in der Anforderung Authentifizierungsdaten angegeben wurden, wird die
Der Server hält sie für unzureichend, um Zugriff zu gewähren. Der Kunde
SOLLTE NICHT automatisch die Anfrage mit wiederholen
Referenzen. Der Client kann die Anforderung mit neuen oder anderen Anmeldeinformationen wiederholen. Eine Anfrage kann jedoch aus bestimmten Gründen untersagt sein
ohne Bezug zu den Anmeldeinformationen.

Ein Origin-Server, der die aktuelle Existenz von a "verbergen" möchte
Verbotene Zielressource KANN stattdessen mit einem Statuscode von antworten
404 Nicht gefunden).

Somit könnte ein 403 (oder ein 404) nun etwas bedeuten. Das Bereitstellen neuer Anmeldeinformationen kann hilfreich sein ... oder auch nicht.

Ich glaube, der Grund, warum sich dies geändert hat, ist die Annahme von RFC 2616, dass die HTTP-Authentifizierung verwendet wird, wenn in der Praxis die heutigen Web-Apps benutzerdefinierte Authentifizierungsschemata erstellen, die beispielsweise Formulare und Cookies verwenden.

44
Erwan Legrand

Dies ist eine ältere Frage, aber eine Option, die nie wirklich angesprochen wurde, war die Rückgabe einer 404. Aus Sicherheitssicht leidet die Antwort mit der höchsten Stimmenzahl unter einer potenziellen Sicherheitsanfälligkeit durch Informationsleckage . Angenommen, es handelt sich bei der fraglichen sicheren Webseite um eine Systemadministrationsseite oder, möglicherweise häufiger, um einen Datensatz in einem System, auf den der Benutzer keinen Zugriff hat. Idealerweise möchten Sie nicht, dass ein böswilliger Benutzer überhaupt weiß, dass eine Seite/Aufzeichnung vorhanden ist, geschweige denn, dass er keinen Zugriff hat. Wenn ich so etwas erstelle, werde ich versuchen, nicht authentifizierte/nicht autorisierte Anforderungen in einem internen Protokoll aufzuzeichnen, aber eine 404 zurückgeben.

OWASP enthält einige weitere Informationen Informationen darüber, wie ein Angreifer diese Art von Informationen als Teil eines Angriffs verwenden kann.

26
Patrick White

Diese Frage wurde vor einiger Zeit gestellt, aber die Leute denken weiter.

Abschnitt 6.5. In diesem Entwurf (verfasst von Fielding und Reschke) hat der Statuscode 403 eine etwas andere Bedeutung als in RFC 2616 .

Es spiegelt wider, was bei Authentifizierungs- und Autorisierungsschemata passiert, die von einer Reihe gängiger Webserver und Frameworks verwendet werden.

Ich habe das hervorgehoben, was ich für am hervorstechendsten halte.

6.5.3. 403 Verboten

Der Statuscode 403 (Verboten) gibt an, dass der Server die Anforderung verstanden hat, sie jedoch nicht autorisiert. Ein Server, der veröffentlichen möchte, warum die Anforderung verboten wurde, kann diesen Grund in der Antwortnutzlast (falls vorhanden) beschreiben.

Wenn in der Anforderung Authentifizierungsinformationen angegeben wurden, sind diese nach Ansicht des Servers nicht ausreichend, um Zugriff zu gewähren. Der Client SOLLTE die Anfrage NICHT mit den gleichen Zugangsdaten wiederholen. Der Client KANN die Anforderung mit neuen oder anderen Anmeldeinformationen wiederholen. Eine Anforderung kann jedoch aus Gründen, die nicht mit den Anmeldeinformationen zusammenhängen, verboten sein.

Ein Origin-Server, der die aktuelle Existenz einer verbotenen Zielressource "verbergen" möchte, antwortet möglicherweise stattdessen mit dem Statuscode 404 (Not Found).

Unabhängig davon, welche Konvention Sie verwenden, ist es wichtig, für Einheitlichkeit auf Ihrer Site/API zu sorgen.

21
Dave Watts

TL; DR

  • 401: Eine Ablehnung, die mit Authentifizierung zu tun hat
  • 403: Eine Ablehnung, die NICHTS mit Authentifizierung zu tun hat

Praxisbeispiele

Wenn Apache eine Authentifizierung erfordert (über .htaccess) und Sie Cancel drücken, antwortet es mit einem 401 Authorization Required

Wenn nginx eine Datei findet, aber keine Zugriffsrechte (Benutzer/Gruppe) zum Lesen/Zugreifen hat, antwortet sie mit 403 Forbidden

RFC (2616 Abschnitt 10)

401 Nicht autorisiert (10.4.2)

Bedeutung 1: Authentifizierung erforderlich

Die Anforderung erfordert eine Benutzerauthentifizierung. ...

Bedeutung 2: Authentifizierung unzureichend

... Wenn die Anforderung bereits Berechtigungsnachweise enthielt, zeigt die Antwort 401 an, dass die Berechtigung für diese Berechtigungsnachweise verweigert wurde. ...

403 Verboten (10.4.4)

Bedeutung: ohne Bezug zur Authentifizierung

... Autorisierung hilft nicht ...

Weitere Details:

  • Der Server hat die Anfrage verstanden, lehnt sie jedoch ab.

  • Es sollte den Grund für die Ablehnung in der Einheit beschreiben

  • Stattdessen kann der Statuscode 404 (Nicht gefunden) verwendet werden

    (Wenn der Server diese Informationen vom Client behalten möchte)

11
Levit

sie sind nicht angemeldet oder gehören nicht zur richtigen Benutzergruppe

Sie haben zwei verschiedene Fälle angegeben; Jeder Fall sollte eine andere Antwort haben:

  1. Wenn sie überhaupt nicht angemeldet sind, sollten Sie 401 Unauthorized zurückgeben.
  2. Wenn sie angemeldet sind, aber nicht zur richtigen Benutzergruppe gehören, sollten Sie 403 Forbidden zurückgeben.

Hinweis zum RFC basierend auf Kommentaren zu dieser Antwort:

Wenn der Benutzer nicht angemeldet ist, ist er nicht authentifiziert. Das HTTP-Äquivalent lautet 401 und wird im RFC irreführend als Nicht autorisiert bezeichnet. As Abschnitt 10.4.2 gibt für 401 Unauthorized an:

"Die Anforderung erfordert eine Benutzerauthentifizierung ."

Wenn Sie nicht authentifiziert sind, ist 401 die richtige Antwort. Wenn Sie jedoch nicht autorisiert sind, ist 403 im semantisch richtigen Sinne die richtige Antwort.

9
Zaid Masud

Das ist in meinem Kopf einfacher als irgendwo hier, also:

401: Sie benötigen eine HTTP-Basisauthentifizierung, um dies zu sehen.

403: Sie können dies nicht sehen, und die HTTP-Basisauthentifizierung hilft nicht weiter.

Wenn sich der Benutzer nur mit dem Standard-HTML-Anmeldeformular Ihrer Site anmelden muss, ist 401 nicht geeignet, da es spezifisch für die HTTP-Basisauthentifizierung ist.

Ich empfehle nicht, 403 zu verwenden, um den Zugriff auf Dinge wie /includes zu verweigern, da diese Ressourcen im Web überhaupt nicht vorhanden sind und daher 404 sein sollten.

Dies lässt 403 als "Sie müssen angemeldet sein".

Mit anderen Worten bedeutet 403 "Diese Ressource erfordert eine andere Form der Authentifizierung als die HTTP-Basisauthentifizierung".

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

3
Vladimir Kornea

Ich denke, es ist wichtig zu bedenken, dass 401 für einen Browser ein Authentifizierungsdialog für den Benutzer initiiert, um neue Anmeldeinformationen einzugeben, während 403 dies nicht tut. Nach Ansicht der Browser sollte sich der Benutzer erneut authentifizieren, wenn ein 401 zurückgegeben wird. 401 steht also für eine ungültige Authentifizierung, während 403 für eine fehlende Berechtigung steht.

Hier sind einige Fälle unter dieser Logik, in denen ein Fehler von der Authentifizierung oder Autorisierung zurückgegeben wird, wobei wichtige Ausdrücke fett gedruckt sind.

  • Eine Ressource erfordert eine Authentifizierung, aber keine Anmeldeinformationen waren angegeben.

401: Der Client sollte Anmeldeinformationen angeben.

  • Die angegebenen Anmeldeinformationen haben ein ngültiges Format.

4: Das ist weder 401 noch 403, da Syntaxfehler immer 400 zurückgeben sollten.

  • Die angegebenen Anmeldeinformationen verweisen auf ein Benutzer welches nicht vorhanden.

401: Der Client sollte gültige Anmeldeinformationen angeben.

  • Die angegebenen Anmeldeinformationen sind ngültig, geben Sie jedoch einen gültigen Benutzer an (oder geben Sie keinen Benutzer an, wenn ein angegebener Benutzer nicht erforderlich ist).

401: Auch hier sollte der Client gültige Anmeldeinformationen angeben.

  • Die angegebenen Anmeldeinformationen haben abgelaufen.

401: Dies ist praktisch dasselbe wie bei ungültigen Anmeldeinformationen im Allgemeinen, daher sollte der Client gültige Anmeldeinformationen angeben.

  • Die angegebenen Anmeldeinformationen sind vollständig gültig, aber nicht ausreichend die bestimmte Ressource, obwohl es möglich ist, dass Anmeldeinformationen mit mehr Berechtigung könnten.

4: Wenn Sie gültige Anmeldeinformationen angeben, wird kein Zugriff auf die Ressource gewährt, da die aktuellen Anmeldeinformationen bereits gültig sind, aber nur keine Berechtigung haben.

  • Die bestimmte Ressource ist nicht zugreifbar unabhängig von Anmeldeinformationen.

4: Dies ist unabhängig von den Anmeldeinformationen. Die Angabe gültiger Anmeldeinformationen kann daher nicht hilfreich sein.

  • Die angegebenen Anmeldeinformationen sind vollständig gültig, aber der bestimmte Client ist blockiert daran gehindert, sie zu verwenden.

4: Wenn der Client blockiert ist, hat die Angabe neuer Anmeldeinformationen keine Auswirkung.

3
Grant Gryczan

401: Ich weiß nicht, wer du bist. Dies ist ein Authentifizierungsfehler. 4: Ich weiß wer du bist. Sie haben jedoch keine Berechtigung, auf diese Ressource zuzugreifen. Dies ist ein Autorisierungsfehler.

1
Akshay Misal

Angesichts der neuesten RFCs zu diesem Thema ( 7231 und 7235 ) scheint der Anwendungsfall ziemlich klar zu sein (Kursivschrift hinzugefügt):

  • 401 ist für nicht authentifiziert ("keine gültige Authentifizierung"); d. h. "Ich weiß nicht, wer Sie sind, oder ich vertraue Ihnen nicht, wer Sie sagen, dass Sie sind."

401 Nicht autorisiert

Der 401-Statuscode (Nicht autorisiert) gibt an, dass die Anforderung nicht angewendet wurde, da es keine gültigen Authentifizierungsdaten für die Zielressource gibt. Der Server, der eine 401-Antwort generiert, MUSS ein WWW-Authenticate-Headerfeld (Abschnitt 4.1) senden, das mindestens eine für die Zielressource geltende Abfrage enthält.

Wenn die Anforderung Anmeldeinformationen für die Authentifizierung enthielt, zeigt die Antwort 401 an, dass die Autorisierung für diese Anmeldeinformationen verweigert wurde. Das Benutzerprogramm KANN die Anforderung mit einem neuen oder ersetzten Feld für den Autorisierungskopf wiederholen (Abschnitt 4.2). Wenn die Antwort 401 die gleiche Herausforderung wie die vorherige Antwort enthält und der Benutzeragent bereits mindestens einmal versucht hat, sich zu authentifizieren, MUSS der Benutzeragent dem Benutzer die beigefügte Darstellung vorlegen, da sie normalerweise relevante Diagnoseinformationen enthält.

  • 403 ist für nicht autorisiert ("verweigert die Autorisierung"); "Ich weiß, wer Sie sind, aber Sie haben keine Berechtigung, auf diese Ressource zuzugreifen."

403 Verboten

Der Statuscode 403 (Verboten) gibt an, dass der Server die Anforderung verstanden hat, sie jedoch nicht autorisiert hat. Ein Server, der veröffentlichen möchte, warum die Anforderung verboten wurde, kann diesen Grund in der Antwortnutzlast (falls vorhanden) beschreiben.

Wenn in der Anforderung Authentifizierungsinformationen angegeben wurden, sind diese nach Ansicht des Servers nicht ausreichend, um Zugriff zu gewähren. Der Client SOLLTE die Anforderung NICHT automatisch mit denselben Anmeldeinformationen wiederholen. Der Client kann die Anforderung mit neuen oder anderen Anmeldeinformationen wiederholen. Eine Anforderung kann jedoch aus Gründen, die nicht mit den Anmeldeinformationen zusammenhängen, verboten sein.

Ein Origin-Server, der die aktuelle Existenz einer verbotenen Zielressource "verbergen" möchte, antwortet möglicherweise stattdessen mit dem Statuscode 404 (Not Found).

0
cjbarth