Immer 403 (Forbidden) beim laden von AWS-CloudFront-Datei

Beim einschränken des Zugriffs auf S3 Inhalt mithilfe eines bucket-Richtlinie, prüft die eingehenden Referer: header, die Sie tun müssen, ein wenig von der benutzerdefinierten Konfiguration "überlisten" CloudFront.

Es ist wichtig zu verstehen, dass CloudFront ist entworfen, um eine gut erzogene cache. Durch "brav" meine ich, dass CloudFront ist entworfen, um nie eine Antwort zurück, die unterscheidet sich von was die origin server wieder zurück haben möchte. Ich bin sicher, Sie können sehen, dass ist ein wichtiger Faktor.

Sagen wir mal ich habe eine web-server (nicht S3) hinter CloudFront, und meine Website ist so konzipiert, dass es gibt unterschiedliche Inhalte basierend auf einer Inspektion der Referer: header... oder andere http-request-header, wie User-Agent: zum Beispiel. Je nach browser, ich könnte andere Inhalte zurück. Wie würde CloudFront wissen, so wäre es zu vermeiden, dient ein user die falsche version von einer bestimmten Seite?

Die Antwort ist, es wäre nicht in der Lage zu sagen -- kann es das nicht wissen. So, CloudFront, die Lösung ist nicht, um nach vorne die meisten Anfrage-Header auf meinem server überhaupt. Was mein web-server nicht sehen kann, kann es nicht reagieren soll, also die Inhalte, die ich zurückgeben kann variieren, basierend auf dem Header habe ich nicht erhalten, die verhindert, dass CloudFront von caching-und Rücksendung der falschen Antwort, basierend auf den Header. Web-caches haben eine Verpflichtung zu vermeiden Rücksendung der falsch zwischengespeicherte Inhalte für eine bestimmte Seite.

"Aber halt", werden Sie Objekt. "Meine Website hängt vom Wert ab einem bestimmten header, um festzustellen, wie Sie darauf reagieren." Richtig, das macht Sinn... so haben wir zu sagen CloudFront dies:

Anstatt caching meiner Seiten auf der Grundlage von nur der angeforderte Pfad, brauche ich Sie, um auch nach vorn die Referer: oder User-Agent: oder eine von mehreren anderen Headern als den vom browser gesendeten, und cache die Antwort für die Verwendung auf anderen Anforderungen, die nicht nur den gleichen Weg, sondern auch die gleichen Werte für die zusätzlichen header(s), die Sie nach vorne zu mir.

Jedoch, wenn der Ursprungs-server ist S3, CloudFront unterstützt keine Weiterleitung meisten Anfrage-Header, auf der Annahme, dass da statische Inhalte kaum unterscheiden, diese Header würde nur dazu führen, es zu cache-mehrere identische Antworten unnötig.

Ihre Lösung ist nicht zu sagen, CloudFront, dass man mit S3 als die Herkunft. Stattdessen konfigurieren Sie Ihren Vertrieb mit einem "custom" - Herkunft, und geben Sie den Hostnamen, den der Eimer zu verwenden, als der origin-server-Hostnamen.

Dann können Sie konfigurieren CloudFront uns die Referer: - header, um die Herkunft und Ihrem S3-bucket-Richtlinie, verweigert/erlaubt Anfragen auf dieser Basis-header funktionieren wird, wie erwartet.

Gut, fast wie erwartet. Dies senkt Ihre cache-Treffer-Verhältnis etwas, da jetzt die zwischengespeicherten Seiten gecached werden, basierend auf Pfad + verweisende Seite. Es wird ein S3-Objekt verwiesen wird, mehr als eine Ihrer Seiten, CloudFront cache-Kopie für jede eindeutige Anfrage. Es klingt wie eine Einschränkung, aber wirklich, es ist nur ein Artefakt der richtigen cache-Verhalten -- was wird an den back-end -, fast alle von es, müssen verwendet werden, um zu bestimmen, ob die betreffende Reaktion ist verwendbar für die Wartung zukünftige Anforderungen.

Sehen http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeaders für die Konfiguration CloudFront whitelist bestimmte Header zu senden, um Ihre origin-server.

Wichtig: nicht nach vorne alle Header, die Sie nicht benötigen, da jede Variante Anfrage senkt Ihre Trefferquote weiter. Insbesondere bei der Verwendung von S3 als back-end für eine individuelle Herkunft, tun uns nicht die Host: header, denn das ist wahrscheinlich nicht gehen, um zu tun, was Sie erwarten. Wählen Sie die Referer: header hier, und testen. S3 sollten beginnen zu sehen, die Kopf-und entsprechend reagieren.

Beachten Sie, dass, wenn Sie entfernt Ihre bucket-Richtlinien für die Prüfung, CloudFront würde weiterhin dienen die zwischengespeicherten Fehler-Seite, es sei denn, Sie spülte Ihren cache durch senden einer request-Invalidierung, die Ursachen CloudFront zu entfernen alle zwischengespeicherten Seiten passend zu den Pfad-Muster, die Sie angeben, im Laufe von etwa 15 Minuten. Die einfachste Sache zu tun beim Experimentieren ist, erstellen Sie einfach eine neue CloudFront-Verteilung mit der neuen Konfiguration, da es keine Gebühr für die Distributionen selbst.

Bei der Anzeige der Antwort-Header aus CloudFront, beachten Sie die X-Cache: (hit/miss) und Age: (vor wie langer Zeit diese Besondere Seite zwischengespeichert wurde) Antworten. Diese sind auch nützlich bei der Fehlersuche.

Update: @alexjs hat eine wichtige Beobachtung: statt dies zu tun, verwenden Sie den Eimer Politik und Weiterleitung der Referer: header S3 für die Analyse -- die verletzen Ihre cache-Verhältnis in einem Maße variiert, dass mit der Verbreitung von Ressourcen über verweisende Seiten-Sie können das neue AWS-Web-Application-Firewall-Dienst, der ermöglicht Ihnen das festlegen von Filterregeln, die gegen eingehenden Anfragen auf CloudFront, zu blockieren oder Anforderungen auf der Basis string-matching in der request-Header.

Dafür müssten Sie verbinden die Verteilung S3 als S3-Herkunft (die normale Konfiguration, im Gegensatz zu dem, was ich vorgeschlagen habe, in die Lösung über, mit einer "custom" - Herkunft) und verwenden Sie die eingebaute Funktion von CloudFront zu authentifizieren back-end-Anforderungen in S3 (also der Eimer Inhalte sind nicht direkt zugänglich, wenn angefordert von S3, die direkt durch eine bösartige Schauspieler).

Sehen https://www.alexjs.eu/preventing-hotlinking-using-cloudfront-waf-and-referer-checking/ um mehr über diese option.

Identifizierte ich ein weiterer Grund, warum CloudFront zurückgeben kann 403 (Bad request). Vielleicht ist das ja ein Grenzfall, aber ich würde gerne mit Ihnen teilen.

CloudFront implementiert einen vorwärts-loop-detection-Mechanismus, um zu verhindern, dass von der Weiterleitung-loop-Angriffe.

Sie können keine Kaskade mehr als 2 CloudFront-Verteilungen als orgins nach den AWS support.

Vermuten lässt, die Sie konfiguriert haben CloudFront mit CloudFront B als Ursprung und von CloudFront B, die Sie konfiguriert haben CloudFront C als Ursprung, und von CloudFront C Sie haben ein S3-bucket als Ursprung.

A --> B --> C --> S3 bucket (can return a 403 error)

Wenn Sie eine Datei von CloudFront Ein, die sich in der S3-bucket am Ende der Kaskade, die CloudFront C zurück 403 (Bad request).

Wenn Ihr cascade besteht nur aus 2 CloudFront-Verteilungen und einem S3-bucket am Ende, die Anfrage einer Datei aus dem S3-Herkunft funktioniert.

A --> B --> S3 bucket (works)