Open benkirbycodes opened 2 years ago
I'm facing the same error in my application using vue. But this error can also be replicated using AWS AppSync, so it might not be a problem with this project.
@benkirbycodes I got this error from the CLI when I tried pushing with your Resource
type.
Do you still experience this behavior if you do one of the actions mentioned? I just added the auth directive to the required ID field and it allowed me to push.
@chrisbonifacio We're actually not getting an error on push. Everything builds fine and we actually get the desired behavior for READ reqs. The fields are just always null for CREATE/UPDATE. The fields that we're trying to lockdown via field-level auth are not required, so that solution wouldn't really be workable for us.
I wasn't able to reproduce the exact behavior described in this issue but I ran into other issues on the client side.
On the AppSync console, queries and mutations seem to behave as expected.
Creating a Resource returns the data
So does updating a Resource
However, trying to create a resource on the client (logged in as the same CognitoUser) results in the "custom:tenant" attribute not being set as the owner. Instead, it seems ___xamznone____
is being set as the tenantId.
I checked my CognitoUser data and the custom:tenant
, of which the value was correctly used as the tenantId
by the AppSync console earlier, is present.
I'm labeling this as a bug for the team to look into further.
Some of the other strange behavior I ran into:
The tenantId for the records created on the client, where the tenantId was set to ___xamznone____
are returned as null
in the AppSync console.
On the client, all records are returned in the response data, but with an Unauthorized error for the records where the tenantId
doesn't match
It looks like this issue is related to aws-amplify/amplify-category-api#64
This issue might be caused by the auto-generated VTL template for the field-level auth directive. As a example:
## [Start] Checking for allowed operations which can return this field. **
#set( $operation = $util.defaultIfNull($ctx.source.get("__operation"), null) )
#if( $operation == "Mutation" )
$util.toJson(null)
#else
$util.toJson($context.source["fieldName"])
#end
## [End] Checking for allowed operations which can return this field. **
If I understand the code well, it just return whenever it is an Mutation
, which is quite weird in this case.
I believe you are on the right track @PlusA2M. The fix for this issue is likely entirely in https://github.com/aws-amplify/amplify-category-api.
I'll leave this issue open for visibility.
Transferring this over to category-api repo as it seems the root cause is in the generated VTL templates
Before opening, please confirm:
JavaScript Framework
React
Amplify APIs
GraphQL API
Amplify Categories
auth, function, api
Environment information
Describe the bug
We have fields on a model that are protected by a field-level auth declaration. The declaration checks whether the user is in a group that has permissions to get the field value.
In the results of a GET request, these declarations are respected. In the results of both CREATE and UPDATE requests though, all users receive
null
for these fields, regardless of their group.Expected behavior
I would expect that the results of CREATE and UPDATE would contain the same fields as a GET request.
This may be a misunderstanding on my part, would love some further info if so
Reproduction steps
type
in a graphqlAPI with the@model
attribute.custom:tenant
value stored in Cognito (not sure if this is relevant to the issue).Code Snippet
Log output
aws-exports.js
No response
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response