Skip to content
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

blbradley opened this issue Sep 26, 2018 · 5 comments

Cognito superuser group or user 'type' #217

blbradley opened this issue Sep 26, 2018 · 5 comments


Copy link

@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.

Copy link

@dennyferra 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.

Copy link

@blbradley 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.

Copy link

@blbradley 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.

Copy link

@WilcoFiers 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.

Copy link

@mikeparisstuff 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 22, 2018
kaustavghosh06 added a commit that referenced this issue Oct 22, 2018
* temp commit

* temp commit

* Fixing dynamic group auth with multiple rules

* Fixing #217

* Working on auth scenarios and adding more tests

* Adding more tests for auth checks.

* Totally restructuring the auth flows for get resolvers. This is a checkin commit as CUDL still remain to be updated

* Adding support for list queries

* Support for create operations in updated auth flows

updating block statements

* Adding back all tests. This concludes fixing the auth bugs

* Adding parens on auth check

* Changing name of test

* Removing unnecessary userGroups variable instantiation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.