Open mausic opened 2 months ago
Hey @mausic, thank you for reaching out. I was able to reproduce the issue, marking this as bug for further improvements.
I too hit this problem today. Spoke with Harshita Daddala about it.
My use case is similar. I have "ADMINS" and "USERS" - USERS is meant to be a benign holding group. I auto assign the users on signup to USERS and have ADMINS who can access everything.
I was surprised to see that the group membership would completely supersede the individual entity level rights.
As a developer, I would expect a UNION of role based security of groups and individual user auth rules set in AUTH.
I was trying to use FileUploader and StorageImage in a client component (nextjs and mostly server-side rendering in my application). The URL was being correctly created in the FileUploader component, with the correct identityId, which is what caused me so much trouble in tracking down what was happening. I eventually inspected the error in the console and saw:
Error uploading file protected/images/{identityId}/{correct rest of path}: User: <snip>assumed-role/amplify-reintern-watso-sa-amplifyAuthUSERSGroupRole-BMAf5LXBRxas/CognitoIdentityCredentials is not authorized to perform: s3:PutObject on resource: "<snip>/protected/images/{identityId}/{rest of path}" because no identity-based policy allows the s3:PutObject action
It wasn't until I noticed "USERSGroupRole" that I zeroed in on the problem. The solve was non-intuitive as I would have thought that setting up my auth as follows would allow for an individual level scoping of auth rights:
export const auth = defineAuth({
loginWith: {
email: {
verificationEmailStyle: 'CODE',
verificationEmailSubject:
'Verification Email for AllTheInterns.com',
verificationEmailBody: (createCode) =>
`Thank you for creating a new user account with AllTheInterns. Please use this code to confirm your account: ${createCode()}`,
},
},
groups: ['ADMINS', 'USERS'],
// triggers: {
// postConfirmation,
// },
// access: (allow) => [
// allow.resource(postConfirmation).to(['addUserToGroup']),
// ],
});
As you can see, I have commented out the triggered lambda which auto-assigns to USERS group. Also removed the impacted user (I'm still in dev mode, so it's a single account) from the USERS group. Permission errors went away.
Environment information
Description
In AWS Amplify Gen 2.0 there is an issue or a bug related to Owner-based storage permissions and auth groups.
If authenticated user is within a Group, for example,
Users
, it is impossible to set up Owner-based access rules for Storage without specifying the same-level group permission. For example.auth
setup atamplify/auth/resource.ts
filestorage
setup atamplify/storage/resource.ts
Users
group.Now, if we try to upload a file such as
we will get
AccessDenied
error.The only way to fix this is to either remove the user from the group (which is breaking business logic relying on user groups) or to change
amplify/storage/resource.ts
file by adding aUsers
group permission to it, such as:which breaks Owner-based storage permissions and allows anyone in the
Users
group to modify other users' files.