Comments for Upload a File to S3

From @jayair on Thu Dec 21 2017 19:30:15 GMT+0000 (UTC)

@SpencerGreene As an exercise, removing the key from the url is okay. But the proper practice would be to store the key and the url.

From @picwell-mgeiser on Fri Dec 29 2017 16:00:09 GMT+0000 (UTC)

I’m getting a CORS error similar but not the same as others

But…I am only getting the CORS error for the upload to the S3. The other Note functions (Create, Update, Delete) work fine in the App…just the actual file upload to the S3 bucket is failing.

I readacted the S3 bucket name:

Chrome
new:1 Failed to load https://s3.amazonaws.com/-----.-----.----/us-east-1%3A4d25e339-bdc1-4c09-9c83-5b99893414ec-1514561788846-ecsv_10_2017%20%282%29.csv: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. The response had HTTP status code 403.

FF
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://s3.amazonaws.com/-----.-----.-----/us-east-1%3A4d25e339-bdc1-4c09-9c83-5b99893414ec-1514568875798-Screen%20Shot%202017-12-24%20at%207.47.28%20PM.png. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

I deleted and recopied the CORS configuration XML. This is what I get in the AWS console
AFTER I save and come back to the CORS config

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

The App does retry the upload 4 times I see from the Developer console. The problem is the 403 CORS issue, however

I can Upload and delete this file to the S3 bucket directly from the console no issues (but this is CORS issue according to message)

Also, what should the ACL of the Bucket contain? We created an IAM user (I called mine reactAppAdmin) but I do not see it in the ACL. I’d suspect it would be under the “Access for other AWS accounts” section. If I need to add this to the secion, how do I determine the “Canonical User Id” for reactAppAdmin? (but this is a CORS issue, right?)

Thoughts?

From @picwell-mgeiser on Fri Dec 29 2017 16:43:06 GMT+0000 (UTC)

Is this error because we’re running the App from localhost and submitting to AWS without the react app setting a ‘Access-Control-Allow-Origin’ header?

How would we set that header in the app can we bump creating the deployed App to earlier in the tutorial and just run the deploy to the S3 App bucket more often (sounds like a good idea to give us React noobs more experience…)

I saw some results on Google where similar errors were from not setting the Region correctly. I don’t see where the Region is set with the s3Upload component use in this example

From @jayair on Sat Dec 30 2017 20:58:55 GMT+0000 (UTC)

@picwell-mgeiser In this chapter - https://serverless-stack.com/chapters/create-a-cognito-identity-pool.html we give permissions to our users to upload to S3. It is in the section where we add the policy for our Identity Pool. Just make sure you have completed this step properly.

From @picwell-mgeiser on Sun Dec 31 2017 05:33:33 GMT+0000 (UTC)

I checked and the permissions look correct.

If I go into the IAM - Roles Cognito_NotesAppPoolAuth_role and expand the Policy and click on S3, under Write, the PutObject Resource =

BucketName | string like | pickme-sandbox-reactapp-files, ObjectPath | string like | ${cognito-identity.amazonaws.com:sub}*

Also, would the error specifically say CORS ‘Access-Control-Allow-Origin’ error if it were a role config error? I know error messages aren’t always 100% spot on accurate, but I’d guess the CORS failure would happen before a ACL check and probably in a different component, so I’m guessing it is unlikely that an ACL error will generate a CORS ‘Access-Control-Allow-Origin’ error…just sayin’ :slight_smile:

How can I better trace and diagnose where exactly this failed?

From @jayair on Sun Dec 31 2017 21:19:47 GMT+0000 (UTC)

@picwell-mgeiser AWS doesn’t make it easy to debug these. The main thing I would check is for typos in these. Make sure the bucket name is correct in the roles and while you are uploading them. And the region as well.

From @jlissner on Thu Jan 18 2018 19:13:39 GMT+0000 (UTC)

@picwell-mgeiser I had the same issue, I had a type in my CORS configuration on my bucket, specifically my last rule was: <AllowedHeader>Authorization</AllowedHeader>
and it needed to be: <AllowedHeader>*</AllowedHeader>

From @danielkaczmarczyk on Thu Jan 25 2018 13:48:07 GMT+0000 (UTC)

I have the very same issue as @picwell-mgeiser does. Have tried all methods in this (and other) threads. I have used an Allow-Control-Origin-* chrome extension to omit the requirement by enabling cross-origin response sharing and it helps with the preflight authorization but doesn’t fix the fact that I get the 301 result. The current error is Response for preflight has invalid HTTP status code 301.

From @jayair on Fri Jan 26 2018 01:13:54 GMT+0000 (UTC)

@danielkaczmarczyk And does this happen just for file uploads? Or for other API calls as well?

From @danielkaczmarczyk on Sat Jan 27 2018 15:43:06 GMT+0000 (UTC)

@jayair Only on file uploads. I try to send a file, first I get a 200 GET from s3 with all cors headers set correctly, and after that, the OPTIONS call gets 301’d, the very same way as @picwell-mgeiser has described.

From @michaelcuneo on Sat Jan 27 2018 20:11:17 GMT+0000 (UTC)

I have a feeling that something has gone and changed on AWS end… my app worked up until about a month back and now all of a sudden it doesn’t, with zero changes on my end at all. The push to database works fine, push to S3 does not. Just like what everyone else is experiencing. I’ve been trying to track this down for ages.

On 28 Jan 2018, at 2:43 am, Daniel Kaczmarczyk notifications@github.com wrote:

@jayair Only on file uploads. I try to send a file, first I get a 200 GET from s3 with all cors headers set correctly, and after that, the OPTIONS call gets 301’d, the very same way as @picwell-mgeiser has described.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

From @bharloe on Sat Jan 27 2018 23:34:08 GMT+0000 (UTC)

For what it’s worth the push to S3 still works fine for my app which I haven’t touched in months

From @jayair on Sun Jan 28 2018 00:04:25 GMT+0000 (UTC)

@danielkaczmarczyk Can you go into the IAM section of your AWS Console and find the role that is being used? Here are some screenshots on how to do it.

Image 1
Image 2
Image 3
Image 4

From @danielkaczmarczyk on Sun Jan 28 2018 10:52:23 GMT+0000 (UTC)

Here’s my IAM policy for cognito

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "mobileanalytics:PutEvents",
                "cognito-sync:*",
                "cognito-identity:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::notes-app-uploads-dan/${cognito-identity.amazonaws.com:sub}*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "execute-api:Invoke"
            ],
            "Resource": [
                "arn:aws:execute-api:us-east-2:*:lg7wxu2y8b/*"
            ]
        }
    ]
}

From @jayair on Mon Jan 29 2018 00:50:45 GMT+0000 (UTC)

@danielkaczmarczyk That looks good. Can you also check the permissions for your S3 bucket?

Image

From @danielkaczmarczyk on Mon Jan 29 2018 06:37:08 GMT+0000 (UTC)

here:

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

1 Like

From @jayair on Mon Jan 29 2018 19:50:28 GMT+0000 (UTC)

@danielkaczmarczyk Yeah that looks okay too. I can try your repo out and see what I can find. Can you publish it?

From @danielkaczmarczyk on Mon Jan 29 2018 20:05:21 GMT+0000 (UTC)

many thanks for the effort, @jayair ! Here’s the backend and here’s the client should you need it

From @jayair on Mon Jan 29 2018 20:33:24 GMT+0000 (UTC)

@danielkaczmarczyk So I tried it out. I noticed that your bucket is in us-east-2. This isn’t a problem but it needs a slight tweak to the code before we do the upload.

  const s3 = new S3({
    region: 'us-east-2',
    params: {
      Bucket: config.s3.BUCKET
    }
  });

I created a new S3 bucket in us-east-2 using the tutorial instructions. And used your code base and my credentials and the upload worked. But it still didn’t work on your bucket.

I cannot check what the settings are on your bucket but can you try re-creating the bucket (and editing the IAM policy for Cognito with the new bucket)?

From @danielkaczmarczyk on Tue Jan 30 2018 07:07:05 GMT+0000 (UTC)

I have created a new bucket, in us-east-2 (Ohio), amended config.js with the new value for BUCKET, amended the IAM policy for Cognito to make sure that I give it access to write to this particular bucket, and I get a 403 Bucket not found as if the authentication didn’t work. No more error details present