Wenn Sie den Zugriff auf S3-Inhalte mithilfe einer Bucket-Richtlinie beschränken, die den eingehenden Header prüft, müssen Sie ein wenig benutzerdefinierte Konfiguration vornehmen, um CloudFront zu "überlisten".
Es ist wichtig zu verstehen, dass CloudFront als Cache entwickelt wurde, der sich gut benimmt. Mit „artig:“ Ich meine, dass Cloudfront ist so konzipiert, nie eine Antwort zurück, die von dem, was wäre der Ursprungsserver unterscheidet zurückgegeben. Ich bin sicher, dass Sie sehen können, dass dies ein wichtiger Faktor ist.
Lasst uns sagen, dass ich einen Web-Server (nicht S3) hinter Cloudfront, und meine Website ist so konzipiert, dass es unterschiedliche Inhalte liefert, basierend auf einer Inspektion des Referer: Header ... oder jede andere http-Request-Header, wie User-Agent: beispielsweise. Abhängig von Ihrem Browser kann ich unterschiedliche Inhalte zurückgeben. Wie würde CloudFront dies wissen, um zu verhindern, dass einem Benutzer die falsche Version einer bestimmten Seite geliefert wird?
Die Antwort ist, es würde nicht sagen können - es kann das nicht wissen. Die Lösung von CloudFront besteht also nicht darin, die meisten Anforderungsheader überhaupt an meinen Server weiterzuleiten. Was meine Web-Server kann nicht sehen, es nicht reagieren kann, so dass der Inhalt kann ich nicht auf Header Ich erhalte nicht variieren Rückkehr basiert, die Cloudfront von Caching verhindert und die falsche Antwort zurückgibt, basierend auf diesen Header. Web-Caches sind verpflichtet, den falschen Cache-Inhalt für eine bestimmte Seite nicht zurückzugeben.
"Aber warten Sie", widersprechen Sie. "Meine Website hängt vom Wert eines bestimmten Headers ab, um zu ermitteln, wie Sie darauf reagieren." Richtig, das macht Sinn ... so müssen wir sagen, dass dies Cloudfront:
Stattdessen meine Seiten zwischenzuspeichern basierend auf nur den gewünschten Pfad, ich brauche dich auch die Referer: oder User-Agent: oder eine von mehreren anderen Header zu übermitteln, wie geschickt durch den Browser, und die Antwort für die Verwendung auf anderen Anfragen zwischenspeichern, die nicht nur den gleichen Weg umfassen, sondern auch die gleichen Werte für die Extra-Header (n), die Sie mich nach vorne. Wenn der Ursprungsserver jedoch S3 ist, unterstützt CloudFront das Weiterleiten der meisten Anforderungsheader nicht, da es unwahrscheinlich ist, dass statischer Inhalt variiert. Diese Header würden nur dazu führen, dass mehrere identische Antworten unnötigerweise zwischengespeichert werden.
Ihre Lösung besteht nicht darin, CloudFront mitzuteilen, dass Sie S3 als Ursprung verwenden. Konfigurieren Sie stattdessen Ihre Distribution eine „custom“ Herkunft zu verwenden, und gibt ihnen den Hostnamen des Löffels als den Ursprungsserver Hostnamen zu verwenden.
Anschließend können Sie CloudFront so konfigurieren, dass der Header an den Ursprung weitergeleitet wird. Ihre S3-Bucket-Richtlinie, die auf diesem Header basierende Anforderungen verweigert oder zulässt, funktioniert wie erwartet.
Nun, fast wie erwartet. Dadurch wird die Cache-Trefferquote etwas verringert, da die zwischengespeicherten Seiten jetzt auf der Seite "Pfad + Verweise" zwischengespeichert werden.Wenn ein S3-Objekt von mehreren Seiten Ihrer Website referenziert wird, speichert CloudFront eine Kopie für jede eindeutige Anfrage. Es klingt wie eine Einschränkung, aber wirklich, es ist nur ein Artefakt des richtigen Cache-Verhaltens - was immer an das Back-End weitergeleitet wird, fast alles, muss verwendet werden, um festzustellen, ob diese bestimmte Antwort für die Bearbeitung zukünftiger Anfragen verwendbar ist.
Siehe http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeaders für die Konfiguration von CloudFront, um bestimmte Header auf die Whitelist zu setzen, die an Ihren Ursprungsserver gesendet werden.
Wichtig: Leiten Sie keine Header weiter, die Sie nicht benötigen, da jede Variantenanforderung Ihre Trefferrate weiter reduziert. Wenn Sie S3 als Back-End für einen benutzerdefinierten Ursprung verwenden, leiten Sie den Header Host: nicht weiter, da dies wahrscheinlich nicht das tut, was Sie erwarten. Wählen Sie hier den Header aus und testen Sie ihn. S3 sollte beginnen, den Header zu sehen und dementsprechend zu reagieren. Wenn Sie Ihre Bucket-Richtlinie zum Testen entfernt haben, hat CloudFront weiterhin die zwischengespeicherte Fehlerseite bereitgestellt, es sei denn, Sie haben den Cache durch Senden einer Ungültigmachungsanforderung gelöscht, wodurch CloudFront alle zwischengespeicherten Seiten löscht, die dem von Ihnen angegebenen Pfadmuster entsprechen , im Laufe von etwa 15 Minuten. Am einfachsten ist es, beim Experimentieren einfach eine neue CloudFront-Distribution mit der neuen Konfiguration zu erstellen, da die Distributionen selbst nicht belastet werden.
Beachten Sie beim Anzeigen der Antwortheader von CloudFront die Antworten X-Cache: (Treffer/Fehlschlag) und Age: (wie lange diese bestimmte Seite zwischengespeichert wurde). Diese sind auch bei der Fehlersuche nützlich.
Update:@alexjs eine wichtige Beobachtung gemacht hat: Statt dies zu tun, den Eimer Politik und Weiterleiten der Referer: Header S3 für die Analyse unter Verwendung - die Cache-Verhältnis in einem Ausmaß verletzt wird, die mit der variiert Verteilung von Ressourcen über verweisende Seiten - Sie können den neuen AWS Web Application Firewall-Dienst verwenden, mit dem Sie Filterregeln für eingehende Anforderungen an CloudFront erzwingen können, um Anfragen basierend auf string matching in request headers zuzulassen oder zu blockieren.
Dazu müssten Sie die Verteilung S3 als S3-Ursprung (die normale Konfiguration, im Gegensatz zu dem, was ich vorgeschlagen, in der obigen Lösung, mit einem "benutzerdefinierten" Ursprung) und verwenden Sie die integrierte die Fähigkeit von CloudFront, Back-End-Anfragen an S3 zu authentifizieren (sodass der Bucket-Inhalt nicht direkt zugänglich ist, wenn er von S3 direkt von einem böswilligen Akteur angefordert wird).
Weitere Informationen zu dieser Option finden Sie unter https://www.alexjs.eu/preventing-hotlinking-using-cloudfront-waf-and-referer-checking/.
Sie haben uns gehen nicht gegeben viel zu. Verwenden Sie vorab signierte URLs? Verweigert Ihre Bucket-Richtlinie Anfragen basierend auf bestimmten Anfrageparametern? –
@ Michael-sqlbot Ich verwende keine vor-signierte URL, nur die Standardkonfiguration. Die von mir festgelegte Richtlinie bestand darin, nur meine URL zu akzeptieren, um die Dateien zu laden. – Shina
So verwenden Sie eine Bucket-Richtlinie mit etwas wie "Condition": { "StringLike": {"aws: Referer": ["http://www.example.com/*"]} } '? –