it-swarm.com.de

Amazon S3-Eimer mit Rückgabe 403 Verboten

Ich habe vor kurzem eine Rails-App geerbt, die S3 zum Speichern von Assets verwendet. Ich habe alle Assets ohne Probleme in meinen S3-Bucket übertragen. Wenn ich jedoch die App so verändere, dass sie auf den neuen Bucket verweist, erhalte ich den Verbotenen Status 403. 

Mein S3-Bucket ist mit den folgenden Einstellungen eingerichtet:

Berechtigungen

Jeder kann auflisten

Bucket-Richtlinien

{
 "Version": "2012-10-17",
 "Statement": [
    {
        "Sid": "PublicReadGetObject",
        "Effect": "Allow",
        "Principal": "*",
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::bucketname/*"
    }
 ]
}

CORS Konfiguration

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
    </CORSRule>
    <CORSRule>
        <AllowedOrigin>https://www.appdomain.com</AllowedOrigin>
        <AllowedMethod>PUT</AllowedMethod>
        <AllowedMethod>POST</AllowedMethod>
        <AllowedMethod>DELETE</AllowedMethod>
        <AllowedHeader>*</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

Statisches Webhosting

Aktiviert.

Was kann ich noch tun, damit die Öffentlichkeit diese Vermögenswerte erreichen kann?

41
thatgibbyguy

Das Problem ist, dass die Übertragung gemäß diesem Thread durchgeführt wurde, was an sich kein Problem darstellt. Das Problem bestand darin, dass der vorherige Entwickler vor der Übertragung keine Berechtigungen für die Dateien geändert hat. Dies bedeutete, dass ich keine der Dateien verwalten konnte, obwohl sie sich in meinem Eimer befanden.

Das Problem wurde gelöst, indem die Dateien sauber aus dem vorherigen Bucket heruntergeladen wurden, die alten Phantomdateien gelöscht wurden, die neuen Dateien erneut hochgeladen wurden und deren Berechtigungen festgelegt wurden, um das Lesen der Dateien durch die Öffentlichkeit zu ermöglichen.

24
thatgibbyguy

Ich weiß, dass dies ein alter Thread ist, aber ich bin gerade auf das gleiche Problem gestoßen. Ich hatte seit Monaten alles am Laufen und es hörte einfach auf zu arbeiten und gab mir einen 403 Forbidden-Fehler. Es stellte sich heraus, dass die Systemuhr der wahre Schuldige war. Ich denke, s3 verwendet eine Art zeitbasiertes Token, das eine sehr kurze Lebensdauer hat. Und in meinem Fall bin ich einfach gelaufen:

ntpdate pool.ntp.org

Und das Problem ging weg. Ich lasse CentOS 6 laufen, wenn es von Relevanz ist. Dies war die Beispielausgabe:

19 Aug 20:57:15 ntpdate[63275]: step time server ip_address offset 438.080758 sec

Hoffe in hilft!

22
Sthe

es kann auch sein, dass eine korrekte Richtlinie gemäß den Amazon-Dokumenten festgelegt werden muss.

http://docs.aws.Amazon.com/AmazonS3/latest/dev/WebsiteAccessPermissionsReqd.html

geben Sie dem betreffenden Eimer diese Richtlinie

{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"PublicReadGetObject",
        "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::YOUR-BUCKET-NAME/*"
      ]
    }
  ]
}
10
Da Rod

Für mich funktionierte keine der anderen Antworten. Dateiberechtigungen, Bucket-Richtlinien und Uhrzeit waren in Ordnung. Für mich war das Thema zeitweilig, und obwohl es banal klingen mag, haben die beiden zuvor für mich gearbeitet:

  1. Melden Sie sich ab und wieder an.
  2. Wenn Sie versuchen, eine einzelne Datei hochzuladen, versuchen Sie, einen Bulk-Upload durchzuführen. Wenn Sie dagegen versuchen, eine einzelne Datei hochzuladen, versuchen Sie, einen Bulk-Upload durchzuführen.
0
entpnerd

Ich hatte das gleiche Problem beim Hinzufügen von * am Ende der Policy-Bucket-Ressource

{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"PublicReadGetObject",
        "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::example-bucket/*"
      ]
    }
  ]
}
0
user3470929

Eine seltsame Sache, die das Problem behoben hat, nachdem ich die richtigen Berechtigungen eingerichtet habe, war, dass ich die Erweiterung aus dem Dateinamen entfernte. Ich hatte also viele Elemente im Bucket, die alle die gleichen Berechtigungen hatten und einige funktionierten und 403 zurückkehrten. Der einzige Unterschied waren die, die nicht funktionierten. Am Ende des Dateinamens befand sich .png. Als ich das entfernte, funktionierten sie gut. Keine Ahnung warum.

0
andrewcockerham