Korrekte S3 + Cloudfront CORS-Konfiguration?

Meine Anwendung speichert Bilder auf S3 und dann proxies, die Ihnen durch Cloudfront. Ich bin begeistert davon, wie die neue S3-CORS-support, so dass ich kann verwenden das HTML5 canvas-Element-Methoden (die ein cross-origin-policy), kann Sie aber nicht konfigurieren mein S3 und Cloudfront richtig. Noch läuft in "nicht abgefangener Fehler: SECURITY_ERR: DOM Exception 18", wenn ich versuche, Sie zu konvertieren Sie ein Bild in ein canvas-element.

Hier ist, was ich habe, so weit:

S3

<CORSConfiguration>
  <CORSRule>
    <AllowedOrigin>MY_WEBSITE_URL</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>*</AllowedHeader>
  </CORSRule>
  <CORSRule>
    <AllowedOrigin>MY_CLOUDFRONT_URL</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
    </CORSRule>
  </CORSConfiguration>

Cloudfront

Herkunft

Origin Protocol Policy: Match Viewer

HTTP Port: 80

HTTPS Port: 443

Verhalten

Origin: MY_WEBSITE_URL

Object Caching: Use Origin Cache Headers

Forward Cookies: None

Forward Query Strings: Yes

Gibt es etwas, was fehlt mir hier?

UPDATE :
Nur versucht, die änderung der überschriften zu

<AllowedHeader>Content-*</AllowedHeader>
<AllowedHeader>Host</AllowedHeader>

basierend auf dieser Frage Amazon S3 CORS (Cross-Origin Resource Sharing) und Firefox-cross-domain-schriftart laden

Immer noch nicht gehen.

UPDATE: MEHR INFO AUF ANFRAGE

Request
URL:https://d1r5nr1emc2xy5.cloudfront.net/uploaded/BAhbBlsHOgZmSSImMjAxMi8wOS8xMC8xOC81NC80Mi85NC9ncmFzczMuanBnBjoGRVQ/32c0cee8
Request Method:GET
Status Code:200 OK (from cache)

UPDATE

Ich denke, meine Anfrage war nicht korrekt, also habe ich versucht die Aktivierung CORS mit

img.crossOrigin = '';

aber dann das Bild nicht geladen und ich bekomme die Fehlermeldung: Cross-origin-image laden verweigert, um Cross-Origin Resource Sharing policy.

Kommentar zu dem Problem
können Sie Ihre post-Anforderung hier ?. wie in Ihren politischen und übergebenen Parameter in post-Anforderung, die beim hochladen in s3. Kommentarautor: Avichal Badaya
warum die POST-Anfrage im Gegensatz zur GET-Anfrage? Kommentarautor: kateray
ok, Sie geben Informationen über die get Anfrage ? Kommentarautor: Avichal Badaya
es ist nur ein 'src' - gibt es eine andere Möglichkeit, die ich sein sollte, die Formatierung der Anfrage? Kommentarautor: kateray
sind Sie in der Lage, zum speichern der Bilder auf s3 ?. ist dies das problem, das Sie immer beim abrufen der Bild? versuchen Sie mit dem link aus Abschnitt details der s3-Objekt. es wird so etwas wie /" >s3.amazonaws.com/<bucketname>... und prüfen Sie, ob Sie weiterhin die Fehlermeldung erhalten.Ich hatte implementiert, die genau das gleiche mit CORS, so, wenn Sie mir mehr details , ich kann Ihnen helfen. Kommentarautor: Avichal Badaya

InformationsquelleAutor der Frage kateray | 2012-09-10

  1. 95

    Am Juni 26, 2014 AWS veröffentlicht richtigen sind Unterschiedlich: Herkunft, Verhalten auf CloudFront, so dass Sie jetzt nur

    1. Set ein CORS-Konfiguration für Ihren S3-bucket, einschließlich

      <AllowedOrigin>*</AllowedOrigin>

    2. In der CloudFront -> Verteilung - > "Verhalten" für diese Herkunft, Verwendung der Forward-Header aus: - Whitelist-option und die whitelist 'Origin' - header.

    3. Warten ~20 Minuten, während CloudFront verbreitet die neue Regel

    Nun Ihre CloudFront-Verteilung Zwischenspeichern soll, unterschiedliche Antworten (mit der richtigen CORS-Header) für die verschiedenen client-Origin-Header.

    InformationsquelleAutor der Antwort Brett

  2. 3

    UPDATE: stimmt nicht mehr mit den letzten änderungen auf CloudFront. Juhu! Siehe die anderen Antworten für die details. Ich verlasse dieses hier für Kontext/Geschichte.

    Problem

    CloudFront nicht unterstützt CORS 100%. Das problem ist, wie CloudFront speichert die Antwort auf die Anfrage. Jede andere Anfrage für die gleiche URL nach, dass in den Cache-Anfrage egal, der Ursprung. Der wichtigste Teil ist, dass es enthält die Antwort-Header, die von der Herkunft.

    Ersten Anfrage vor CloudFront hat alles im Cache Origin: http://example.com hat einen Antwort-header:

    Access-Control-Allow-Origin: http://example.com

    Zweiten Antrag Origin: https://example.com (beachten Sie, dass HTTPS nicht HTTP) hat auch die response-header:

    Access-Control-Allow-Origin: http://example.com

    Weil das ist, was CloudFront Cache für die URL. Dies ist ungültig -- die browser-console (in Chrome mindestens) eine CORS Verletzung Nachricht und Dinge brechen.

    Abhilfe

    Den vorgeschlagenen arbeiten rund um verschiedene URLs für verschiedene Ursprünge. Der trick ist, fügen Sie eine einzigartige query-string, der anders ist, damit es einen zwischengespeicherten Datensatz pro Herkunft.

    Also unsere URLs wäre so etwas wie:

    http://.../some.png?http_mysite.com
https://.../some.png?https_mysite.com

    Diese Art von Werken, sondern jeder kann machen Ihre Website schlecht arbeiten durch Austausch der Abfragezeichenfolgen. Ist das wahrscheinlich? Wahrscheinlich nicht, aber das Debuggen dieses Problems ist ein riesiger Aufwand.

    Rechts Problemumgehung ist die Verwendung nicht CloudFront mit CORS, bis Sie vollständig unterstützt CORS.

    In Der Praxis

    Wenn Sie CloudFront für CORS, haben einen fallback auf eine andere Methode, die funktioniert, wenn CORS nicht. Dies ist nicht immer eine option, aber bis jetzt bin ich dynamisch laden von Schriftarten mit JavaScript. Wenn die CORS-basierte Anforderung an CloudFront ausfällt, Falle ich zurück auf einen server-side proxy, um die Schriftarten (nicht über origin). Diese Art, Dinge zu halten, zu arbeiten, obwohl CloudFront hab irgendwie ein schlechtes Cache-Eintrag für die schriftart.

    InformationsquelleAutor der Antwort Cymen

  3. 1

    Nicht ganz sicher, was Ihr Problem ist aber:

    https://forums.aws.amazon.com/thread.jspa?messageID=377513

    beantwortet einige von meinen problem mit CORS, S3 und Cloudfront.

    Fand ich auch, dass einige der Vermögenswerte in einen Eimer zurückkehren würde, mit der richtigen CORS-Header und einige nicht. Nach der Aufhebung der Vermögenswerte, die Sie kam zurück, mit den richtigen Headern, nicht sicher, warum einige ungültig, und andere nicht wie die hochgeladen wurden, zur gleichen Zeit, gleicher Typ, gleiche Eimer 🙁

    InformationsquelleAutor der Antwort Jim

Schreibe einen Kommentar