1

We have a bucket that we need the CORS configuration to be like this:

<CORSRule>
  <AllowedOrigin>*</AllowedOrigin>
  <AllowedHeader>*</AllowedHeader>
  <AllowedMethod>GET</AllowedMethod>
</CORSRule>

We need it like that so we can export the images from canvas without getting tainted canvas error.

We did this no more than 3 weeks ago in a different project and it worked just fine, the admin would modify the CORS config and I could see new config even though I couldn't edit it.

Today we tried it and he saves the new configuration and I keep seeing the default one, which is this:

  <CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>Authorization</AllowedHeader>
  </CORSRule>

If he logs in he sees the configuration required, but I'm still getting the tainted canvas error.

So we 3 questions:

  1. How does he set the bucket permissions for me to be able to edit the CORS? We gave all permissions to Authenticated Users for the bucket and I still can't modify the CORS config.
  2. Does anyone know what the problem may be with this, is the * wildcard no longer allowed with AWS S3?
  3. If the wildcard is no longer valid, how can I send an authorized header in the request?

Thanks in advanced for the help.

1 Answers1

1

Permission for setting CORS is granted to users via Identity and Access Management (IAM), not bucket-level permissions, eg:

{
  "Id": "SomeID",
  "Statement": [
    {
      "Sid": "SomeSID",
      "Action": [
        "s3:GetBucketCORS",
        "s3:PutBucketCORS"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::BUCKET-NAME",
      "Principal": {
        "AWS": [
          "USERNAME"
        ]
      }
    }
  ]
}

I was successfully able to edit a CORS policy on a bucket, using the Rule that you provided above. (I did not test that it worked, but I was able to save it as a policy.)

John Rotenstein
  • 241,921
  • 22
  • 380
  • 470