amplify-category-api

amplify-category-api copied to clipboard

Environment information

System:
  OS: macOS 14.4.1
  CPU: (12) arm64 Apple M2 Pro
  Memory: 166.63 MB / 32.00 GB
  Shell: /bin/zsh
Binaries:
  Node: 20.9.0 - ~/.nvm/versions/node/v20.9.0/bin/node
  Yarn: undefined - undefined
  npm: 10.1.0 - ~/.nvm/versions/node/v20.9.0/bin/npm
  pnpm: undefined - undefined
NPM Packages:
  @aws-amplify/backend: 0.13.0
  @aws-amplify/backend-cli: 0.12.0
  aws-amplify: 6.0.29
  aws-cdk: 2.138.0
  aws-cdk-lib: 2.138.0
  typescript: 5.4.5
AWS environment variables:
  AWS_STS_REGIONAL_ENDPOINTS = regional
  AWS_NODEJS_CONNECTION_REUSE_ENABLED = 1
  AWS_SDK_LOAD_CONFIG = 1
No CDK environment variables

Description

Allow guest/unauthenticated users to own data that they create so that only they can see/update the resources that they have created (within the current session), specifically within dynamodb records. I've seen there are ways to do this in gen 1 but it's not clear how to do this in gen 2. I've tried with the following model auth for example with no luck, using both iam and userPool auth mode: .authorization(allow => [allow.owner(), allow.guest().to(['create'])]).

Hey👋 thanks for raising this! I'm going to transfer this over to our API repository for better assistance 🙂

hi, any suggestions?

I've been trying to find a way to set a custom owner field value for unauthorized users so only they can see records they have created for the duration of their active session.

One approach I've looked into is using a lambda custom authorizer but have had no luck. I've been able to capture the identity pool session identityId in the browser client using fetchAuthSession e.g. {identityId=eu-west-2:200c02ef-a475-c65f-663f-c12345678xx} and pass this into a dynamodb table, so could feasibly pass this to a lambda custom authorizer. But its not clear if/how the custom authorizer might then output in a way which could be used to set a custom owner value. Is this possible?

From the docs it doesn't appear possible to set an owner that isn't using userPools or oidc auth. And userPools don't appear to support unauthorized auth (which requires iam auth to be set). Is it possible to set unauthorized auth using userPool auth?

Or is it perhaps possible to use oidc auth to configure a custom owner value without having to provide oidc details such as oidcIssuerUrl?

hi, any suggestions?

I've been trying to find a way to set a custom owner field value for unauthorized users so only they can see records they have created for the duration of their active session.

One approach I've looked into is using a lambda custom authorizer but have had no luck. I've been able to capture the identity pool session identityId in the browser client using fetchAuthSession e.g. {identityId=eu-west-2:200c02ef-a475-c65f-663f-c12345678xx} and pass this into a dynamodb table, so could feasibly pass this to a lambda custom authorizer. But its not clear if/how the custom authorizer might then output in a way which could be used to set a custom owner value. Is this possible?

From the docs it doesn't appear possible to set an owner that isn't using userPools or oidc auth. And userPools don't appear to support unauthorized auth (which requires iam auth to be set). Is it possible to set unauthorized auth using userPool auth?

Or is it perhaps possible to use oidc auth to configure a custom owner value without having to provide oidc details such as oidcIssuerUrl?

We are using "anonymous" accounts. We create for our user a [email protected] account in the userpool. And later when the user wants create an account, we just change the email of the account instead of create a new one, so that the username (sub) is still the same.

👋 @domthomas1,

I've been trying to find a way to set a custom owner field value for unauthorized users

owner based auth means that the user is already signed-in via the provider. If you want to set the custom owner field for unauhorized users, you would want to use a custom authorizer for your use-case as suggested in comments above.

Hey 👋 , This issue is being closed due to inactivity. If you are still experiencing the same problem and need further assistance, please feel free to leave a comment. This will enable us to reopen the issue and provide you with the necessary support.

This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.