add storage access rules to outputs

[rtpascual]

Problem

Storage access rules defined in defineStorage are not in amplify_outputs.json.

Issue number, if available:

Changes

Adds storage access rules to amplify_outputs.json. Considering the following backend code:

// amplify/storage/resource.ts

export const storage = defineStorage({
  name: 'myBucket',
  access: (allow) => ({
    'media/*': [allow.authenticated.to(['read', 'write', 'delete'])],
    'other/*': [
      allow.guest.to(['read']),
      allow.authenticated.to(['read', 'write'])
    ]
  })
});

The outputs for storage will be (note: read is replaced with get and list):

"storage": {
  "aws_region": "us-east-1",
  "bucket_name": "amplify-myapp-mybucket",
  "buckets": [
    {
      "name": "myBucket",
      "bucket_name": "amplify-myapp-mybucket",
      "aws_region": "us-east-1",
      "paths": {
        "media/*": {
          "authenticated": ["get", "list", "write", "delete"]
        },
        "other/*": {
          "guest": ["get", "list"],
          "authenticated": ["get", "list", "write"]
        }
      }
    }
  ]
}

Corresponding docs PR, if applicable:

Validation

E2E and unit tests

Checklist

• If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
• If this PR requires a change to the Project Architecture README, I have included that update in this PR.
• If this PR requires a docs update, I have linked to that docs PR above.
• If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[changeset-bot]

🦋 Changeset detected

Latest commit: 3471c97

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages

Name	Type
@aws-amplify/client-config	Minor
@aws-amplify/backend-output-schemas	Patch
@aws-amplify/integration-tests	Patch
@aws-amplify/backend-storage	Patch
@aws-amplify/backend	Patch
@aws-amplify/backend-cli	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ashika112]

Overall change looks good to me.

Question on npx ampx generate outputs, will customer be able to specify and generate version like 1, 1.1, 1.2?

[rtpascual]

Question on npx ampx generate outputs, will customer be able to specify and generate version like 1, 1.1, 1.2?

Yes they can specify using the --outputs-version option

[AllanZhengYP]

I notice the access can be 1 of enum value from 2 sets: read | write | delete or get | list | write | delete. Is it possible the output file only use the later one? It would make client side logic a lot easier.

[AllanZhengYP]

The DX from the PR description makes sense. The JS library can resolve which of the authenticated, guest, owner, group the caller belongs to, but I'm not sure about the behavior of Functions. How does the client side know whether the client has the permission based on the Functions? I'm referring to this doc: https://docs.amplify.aws/flutter/build-a-backend/storage/authorization/#access-types

[rtpascual]

I notice the access can be 1 of enum value from 2 sets: read | write | delete or get | list | write | delete. Is it possible the output file only use the later one? It would make client side logic a lot easier.

Yes we can make this change

[rtpascual]

The DX from the PR description makes sense. The JS library can resolve which of the authenticated, guest, owner, group the caller belongs to, but I'm not sure about the behavior of Functions. How does the client side know whether the client has the permission based on the Functions? I'm referring to this doc: https://docs.amplify.aws/flutter/build-a-backend/storage/authorization/#access-types

Functions specifically have separate logic through environment variables that reference the resource they are given access to to avoid circular dependencies. For more information see https://docs.amplify.aws/flutter/build-a-backend/functions/grant-access-to-other-resources/.