Ein 403 ist nicht immer eine Ablehnung

Was der 403 tatsächlich gesagt hat

Die Seite besteht aus Dateien in privatem Objektspeicher, ausgeliefert über ein Content-Netzwerk. Der Speicher ist so konfiguriert, wie er sein soll: Er weist alle ab außer der einen Distribution, die lesen darf, und diese Distribution darf ein benanntes Objekt holen und sonst nichts. Sie kann nicht auflisten, was darin liegt.

Wenn also eine Anfrage für eine Seite kommt, die es nicht gibt, muss der Speicher entscheiden. Er weiß, dass das Objekt nicht da ist. Aber der Aufrufer darf nicht wissen, was im Bucket liegt und was nicht, und die Antwort "nicht gefunden" würde genau das verraten. Fragen Sie tausend Namen ab, sammeln Sie die Antworten, und Sie haben einen privaten Bucket kartiert, ohne je ein Byte lesen zu dürfen.

Also antwortet er in beiden Fällen mit 403. Die ehrliche Übersetzung lautet nicht "Sie dürfen nicht". Sie lautet: Hier ist nichts, und ich werde das nicht bestätigen.

Das ist kein Fehler und keine Marotte. Es ist eine bewusste Eigenschaft, und es ist das richtige Verhalten. Der Fehler liegt danach: Das Content-Netzwerk hat diese Antwort unverändert an einen Menschen durchgereicht, der nur eine Seite wollte.

Hier ist nichts, und ich werde das nicht bestätigen.

Die übliche Lösung, und warum sie schlimmer ist als das Problem

Wer nach diesem Fehler sucht, bekommt meistens den Rat, eine Richtlinie hinzuzufügen, die den Bucket für alle lesbar macht, oder das öffentliche Website-Hosting im Speicher selbst einzuschalten.

Es sieht aus, als funktioniere es. Fehlende Seiten antworten plötzlich mit 404, das XML verschwindet, und das Problem wirkt gelöst.

Tatsächlich wurde getauscht. Ein kosmetisches Problem gegen ein echtes: Ein Speicher, der über genau einen kontrollierten Eingang erreichbar war, ist jetzt für jeden lesbar, der einen Namen errät. Jede Datei darin, nicht nur die Seiten. Die oben beschriebene Schutzeigenschaft, die Fremde daran hindert, den Bucket zu kartieren, wurde absichtlich abgeschaltet, um eine Fehlermeldung zu verschönern.

Es lohnt sich, kurz zu spüren, wie verkehrt das ist. Der Rat lautet, das zu schwächen, was richtig funktioniert hat, um das zu beheben, was lediglich unhöflich war.

Was stattdessen zu tun ist

Lassen Sie den Speicher genau so, wie er ist. Übersetzen Sie die Antwort an der Kante, dort wo gleich ein Mensch mitliest.

Auf der Distribution zwei eigene Fehlerantworten. Fangen Sie 403 ab, liefern Sie Ihre eigene Seite aus, und geben Sie den Status 404 zurück. Dann dasselbe für 404, damit Sie nie wieder überlegen müssen, welcher es war. Zehn Minuten für zwei Seiten, und es kostet nichts.

Der Statuscode ist genauso wichtig wie die Seite. Wer eine freundliche Seite ausliefert, aber weiterhin mit 403 antwortet, wird von einer Suchmaschine als Verweigerung gelesen und nicht als verschwundene Seite. Die Adresse bleibt im Index und wartet auf eine Erlaubnis, die nie kommt. Ein 404 sagt die Wahrheit: Da war nie etwas.

Und weil die Seite von der Website kommt und nicht aus dem Speicher, ist es Ihre Seite. In zwei Sprachen, mit einem Weg zurück, im Aussehen der übrigen Seite.

Die allgemeine Form davon

Ein Fehlercode beschreibt nicht, was passiert ist. Er beschreibt, was das System bereit ist, über das Geschehene zu sagen, gegenüber dieser fragenden Person, gemessen daran, was sie wissen darf.

Das sind zwei verschiedene Dinge, und in der Lücke dazwischen liegen die teuren halben Stunden. Der Reflex bei einem 403 ist, an den Berechtigungen zu drehen, weil das Wort dorthin zeigt. Manchmal stimmt das. Manchmal sind die Berechtigungen genau richtig, und das einzige Problem ist, dass eine vorsichtige Antwort, gedacht für eine Maschine, unredigiert an einen Menschen gereicht wurde.

Übersetzen Sie an der Grenze. Lassen Sie das System innen so vorsichtig sein, wie es möchte.

Quellen

Alles oben Genannte ist überprüfbar, und es lohnt sich, die Originaldokumente zu lesen statt der Blogbeiträge, die Ihnen raten, den Bucket zu öffnen.

Why does Amazon S3 return 403 instead of 404 when the object does not exist, AWS re:Post. Das Verhalten, von AWS selbst beschrieben, samt Begründung.

Troubleshoot access denied errors in Amazon S3, AWS-Dokumentation. Die vollständige Liste dessen, was ein 403 sonst bedeuten kann, für die Fälle, in denen es wirklich die Berechtigungen sind.

Generate custom error responses, Amazon-CloudFront-Dokumentation. Die oben beschriebene Lösung, einschließlich der Frage, wie man einen anderen Statuscode zurückgibt als den, den der Ursprung geliefert hat.