New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cognito superuser group or user 'type' #217

Open
blbradley opened this Issue Sep 26, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@blbradley

blbradley commented Sep 26, 2018

Is your feature request related to a problem? Please describe.
Cannot create a user or group with full access privileges to all GraphQL queries and data.

Describe the solution you'd like
Some kind of superuser feature such that a business or support person can help end users.

Describe alternatives you've considered
Could likely implement with custom resolvers (#74), but perhaps there is a better way that applies to generated resolvers.

Additional context
Not yet.

@dennyferra

This comment has been minimized.

Show comment
Hide comment
@dennyferra

dennyferra Sep 29, 2018

I'm looking for something similar to this. I tried getting it to work by adding multiple rules to my GraphQL schema, in the hopes that it would auth owner OR groups:

  @auth(rules: [
    { allow: owner },
    { allow: groups, groups: ["admin"] }
  ])

but Mutation (create) as an owner fails with an Unauthorized error since it only checks if the user is in one of the allowed groups - (owner is required but it never sets $isAuthorized to true). If $isAuthorized was set to true after the ownership injection... here:

public ownerCreateResolverRequestMappingTemplateSnippet = (
it would fix the create issue (assuming no other issues with update/delete). You could then have "superuser"-like functionality by just including an admin group.

The Query resolvers (get, list) look like they will work fine since it checks owner OR group by each individually setting $isAuthorized.

dennyferra commented Sep 29, 2018

I'm looking for something similar to this. I tried getting it to work by adding multiple rules to my GraphQL schema, in the hopes that it would auth owner OR groups:

  @auth(rules: [
    { allow: owner },
    { allow: groups, groups: ["admin"] }
  ])

but Mutation (create) as an owner fails with an Unauthorized error since it only checks if the user is in one of the allowed groups - (owner is required but it never sets $isAuthorized to true). If $isAuthorized was set to true after the ownership injection... here:

public ownerCreateResolverRequestMappingTemplateSnippet = (
it would fix the create issue (assuming no other issues with update/delete). You could then have "superuser"-like functionality by just including an admin group.

The Query resolvers (get, list) look like they will work fine since it checks owner OR group by each individually setting $isAuthorized.

@blbradley

This comment has been minimized.

Show comment
Hide comment
@blbradley

blbradley Sep 29, 2018

I think, in the long term, having users pass a custom boolean expression to the transformer via the schema would be the most expressive solution. Actually, the current schema generation situation is a chain of AND expressions against the auth rules.

blbradley commented Sep 29, 2018

I think, in the long term, having users pass a custom boolean expression to the transformer via the schema would be the most expressive solution. Actually, the current schema generation situation is a chain of AND expressions against the auth rules.

@blbradley

This comment has been minimized.

Show comment
Hide comment
@blbradley

blbradley Sep 29, 2018

i.e. boolean logic for current implementation of your schema

isOwner && isInGroup(x for x in cognitoGroups) is what this tool generates for you, right now.

blbradley commented Sep 29, 2018

i.e. boolean logic for current implementation of your schema

isOwner && isInGroup(x for x in cognitoGroups) is what this tool generates for you, right now.

@WilcoFiers

This comment has been minimized.

Show comment
Hide comment
@WilcoFiers

WilcoFiers Oct 2, 2018

Was trying the same admin rule thing @dennyferra tried. Can't really see a good reason why that wouldn't be the way it worked. Would be nice if it did.

WilcoFiers commented Oct 2, 2018

Was trying the same admin rule thing @dennyferra tried. Can't really see a good reason why that wouldn't be the way it worked. Would be nice if it did.

@mikeparisstuff

This comment has been minimized.

Show comment
Hide comment
@mikeparisstuff

mikeparisstuff Oct 9, 2018

Contributor

@dennyferra What you are doing should work but I believe it was a bug when using both group auth and owner auth together. This should be fixed in this PR #285. I'll add this exact case as a test case to verify.

Contributor

mikeparisstuff commented Oct 9, 2018

@dennyferra What you are doing should work but I believe it was a bug when using both group auth and owner auth together. This should be fixed in this PR #285. I'll add this exact case as a test case to verify.

mikeparisstuff pushed a commit to mikeparisstuff/amplify-cli that referenced this issue Oct 10, 2018

Paris

mikeparisstuff pushed a commit to mikeparisstuff/amplify-cli that referenced this issue Oct 10, 2018

mikeparisstuff pushed a commit to mikeparisstuff/amplify-cli that referenced this issue Oct 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment