Amplify-js: Clarify some steps in Storage related documentation

[nomadus]

Do you want to request a feature or report a bug?
This is mainly a documentation clarification request

What is the current behavior?
Some steps needs to be clarified, such as:

1. Do we need to change S3 permissions apart CORS configuration provided in the documentation https://aws.github.io/aws-amplify/media/storage_guide? By default S3 bucket is created with private access only and upload of a file with public access fails with HTTP 403 access denied error;

1. How to permit only specific user (or role) to access files created by another user or users? In the documentation it says

   Files with private access level are only accessible for specific authenticated users only.
   But it does not clarify how could we achieve this?

2. It is not clear what are the differences between PhotoPicker and S3Image and TextPicker and S3Text components, please add some use cases to distinguish in which cases each component are recommended to use.

[richardzcode]

I can answer the third question.

Pickers are widgets which help load files. They are not tied with S3 service.

S3Image and S3Text wrap PhotoPicker and TextPicker respectively. They work with S3 service. By providing path to S3Image and S3Text they manage upload/update/display by themselves without additional code.

S3Image and PhotoPicker work with image files. S3Text and TextPicker work with text files.

[hassankhan]

I might have some answers for 1 and 2, but I'm afraid they're incomplete since I haven't managed to figure out what else is missing.

If you are using Cognito for authentication, then you must add a policy allowing your federated users access to the S3 bucket. This policy can also be used to restrict users from accessing each others' files.

The best way to see what needs doing is to create a fresh account and use IAM credentials from that to set up a new awsmobile-cli project. I did the same to get the following policy:

Cognito Federated User IAM Policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "<s3_bucket_arn>/public/*",
                "<s3_bucket_arn>/protected/${cognito-identity.amazonaws.com:sub}/*",
                "<s3_bucket_arn>/private/${cognito-identity.amazonaws.com:sub}/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "<s3_bucket_arn>/protected/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": [
                "<s3_bucket_arn>/uploads/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "<s3_bucket_arn>"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "public/",
                        "public/*",
                        "protected/",
                        "protected/*",
                        "private/${cognito-identity.amazonaws.com:sub}/",
                        "private/${cognito-identity.amazonaws.com:sub}/*"
                    ]
                }
            }
        }
    ]
}

However, even after adding the policy for both authenticated and unauthenticated users, I couldn't get the 403 errors to go away.

I then tried something different - I made a Serverless project that has a single (AWS_IAM authorized) endpoint that returns the result of s3.createPresignedPost(). Now, if I call this endpoint, and use the result to dynamically generate a form and submit it, the upload goes through perfectly.

From my experimentation, I would say it most definitely seems like an IAM issue at play, but since the error output in the browser is terrible, so I'm not sure of what the actual error is.

[hassankhan]

@powerful23 Can you clarify why you closed the issue without any explanation, please? This is a significant issue for people who haven't used the awsmobile-cli tool to create their AWS stacks.

[powerful23]

@hassankhan Sorry about that. I thought you have answered that question but seems like not, will reopen it.
Also I have some supplement about question 1 and 2:

1. To make your S3 bucket public to your guest users, if you are using Cognito Federated Identity Pool, you can assign an IAM role to your unauthenticated access and in that role grant the permission to access certain public path in your bucket.

1. Like above, you need to change your IAM policy for your authenticated users to access those private or protect path. https://aws.github.io/aws-amplify/media/storage_guide#customization may help you to set your customized path.