Describe the bug
When combining the following schema GraphQL Transform rules:
type Performance @model @auth(rules: [
{ allow: groups, groups: ["Admin"]},
{ allow: private, operations: [read] }
]) {
id: ID!
performer: String!
description: String!
}
Private access returns an empty response. When signed in as an Admin, the query returns as expected.
The issue seems to be with this resolver:
__ListPerformances response mapping template__
## [Start] Determine request authentication mode **
#if( $util.isNullOrEmpty($authMode) && !$util.isNull($ctx.identity) && !$util.isNull($ctx.identity.sub) && !$util.isNull($ctx.identity.issuer) && !$util.isNull($ctx.identity.username) && !$util.isNull($ctx.identity.claims) && !$util.isNull($ctx.identity.sourceIp) && !$util.isNull($ctx.identity.defaultAuthStrategy) )
#set( $authMode = "userPools" )
#end
## [End] Determine request authentication mode **
## [Start] Check authMode and execute owner/group checks **
#if( $authMode == "userPools" )
## [Start] Static Group Authorization Checks **
#set($isStaticGroupAuthorized = $util.defaultIfNull(
$isStaticGroupAuthorized, false))
## Authorization rule: { allow: groups, groups: ["Admin"], groupClaim: "cognito:groups" } **
#set( $userGroups = $util.defaultIfNull($ctx.identity.claims.get("cognito:groups"), []) )
#set( $allowedGroups = ["Admin"] )
#foreach( $userGroup in $userGroups )
#if( $allowedGroups.contains($userGroup) )
#set( $isStaticGroupAuthorized = true )
#break
#end
#end
## [End] Static Group Authorization Checks **
## [Start] If not static group authorized, filter items **
#if( ! $isStaticGroupAuthorized )
#set( $items = [] )
#foreach( $item in $ctx.result.items )
## No Dynamic Group Authorization Rules **
## No Owner Authorization Rules **
#if( ($isLocalDynamicGroupAuthorized == true || $isLocalOwnerAuthorized == true) )
$util.qr($items.add($item))
#end
#end
#set( $ctx.result.items = $items )
#end
## [End] If not static group authorized, filter items **
#end
## [End] Check authMode and execute owner/group checks **
$util.toJson($ctx.result)
Specifically, this logic:
#if( ! $isStaticGroupAuthorized )
#set( $items = [] )
#foreach( $item in $ctx.result.items )
## No Dynamic Group Authorization Rules **
## No Owner Authorization Rules **
#if( ($isLocalDynamicGroupAuthorized == true || $isLocalOwnerAuthorized == true) )
$util.qr($items.add($item))
#end
#end
#set( $ctx.result.items = $items )
#end
Seems that both isLocalDynamicGroupAuthorized and isLocalOwnerAuthorized are resolving to false, therefore the empty array never gets populated with the items.
If this logic can be updated, or maybe even isLocalOwnerAuthorized can be set to true, this should work.
Amplify CLI Version
3.17.0
To Reproduce
Use the above referenced schema to create a new AppSync API using the Amplify CLI.
Expected behavior
Private access allows users to query data.
cc @attilah @kaustavghosh06 @undefobj
+1. I can confirm I had this last week too. Same is true when using custom queries with @key when static group auth is in place.
type Flight
@model(subscriptions: null)
@auth(rules:[
{allow: groups, groups: ["Admin"]} # commenting this line removes resolver static auth logic
{allow: private, operations: [read]}
])
@key(name: "ByDepartureSchedule",
fields: ["departureAirportCode", "arrivalAirportCode", "departureDate"],
queryField: "getFlightBySchedule")
{
...
}
@dabit3 @heitorlessa please confirm which auth mode is the default and which one is the additional ones the API?
@attilah Default auth mode for me was __Amazon Cognito User Pool__, no additional for me.
@dabit3 Thanks, will look into it!
@attilah one other comment: I would also expect this to work, is it's my final schema that I'm actually working towards (similar issue though, so I'm assuming the fix you're doing now will also resolve the nested resolver):
type Performance @model @auth(rules: [
{ allow: groups, groups: ["Admin"]},
{ allow: private }
]) {
id: ID!
performer: String!
description: String!
time: AWSDateTime
stage: Stage! @connection
}
type Stage @model
@auth(rules: [
{ allow: groups, groups: ["Admin"]},
{ allow: private }
])
{
id: ID!
name: String!
}
@attilah same as @dabit3 - Cognito User Pools as the default auth mode
I found the root cause of the issue. The fix involves code modification to the resolver as @dabit3 said. This rule combination was a missing scenario, hence the error.
@attilah I believe this used to work. I have rules that have existed in my schema for a while that use this combination, and only recently started having problems. if it helps with development and/or where to look, it's possible this is a regression from a previous state. Thanks for looking into this.
Most helpful comment
I found the root cause of the issue. The fix involves code modification to the resolver as @dabit3 said. This rule combination was a missing scenario, hence the error.