Unable to use "iam" authorization for custom mutations in v6.2 about amplify-js

[chrisbonifacio]

Hi @gpavlov2016 can you try changing your mutations handler from custom to function?

ex:

const schema = a.schema({
  Impression: a
    .model({
      videoId: a.string().required(),
      impressions: a.integer().default(0),
    })
    .identifier(["videoId"])
    .authorization((allow) => [allow.publicApiKey(), allow.authenticated()]),

  //Executes atomic increment operation on the impressions field of the Impression model
  increaseImpression: a
    .mutation()
    .arguments({
      videoId: a.string(),
      count: a.integer(),
    })
    .returns(a.ref("Impression"))
    .authorization((allow) => [allow.authenticated()])
    .handler(a.handler.function(incrementImpression)),
});

Mutation performed from the AppSync console with IAM:

[chrisbonifacio]

Although, I am a little confused about the shared code. Your mutation is using the Lambda as the handler but the handler's logic is also invoking the mutation.

So, the mutation is invoking itself? Is that intentional?

[gpavlov2016]

Apologies for the confusion, there are two different functions, I probably should have picked better names for them. Let me try to explain the situation:

• I need to call the increment impression custom mutation from Android
• Android Amplify framework currently doesn't support custom mutations issue open here
• As a solution I created a lambda function (increaseImpression) that can be called through a REST API endpoint that in turn will call the custom increment impression mutation.
• I used IAM authentication to authorize the Lambda to execute the mutation.
• With the 6.2 update the IAM authentication has been removed so I am back to square one - call increment impression custom mutation from Android doesn't work.

So it's not really the mutation handler that I need to authorize but an external function to invoke that handler through GraphQL.

One of the ideas that I am exploring based on your suggestion is to use a function handler instead of custom resolver for the custom mutation implementation but unfortunately the documentation omits the example for this use case and instead shows how to implement a query handler that doesn't include accessing the DB. Link to documentation

[chrisbonifacio]

Oh okay, I see. In that case, the schema level allow.resources should suffice 🤔

I'll try to reproduce again with an external lambda that is separate from the handler

[domthomas1]

@chrisbonifacio hi, in the docs i can see a reference to allow.resource however this isn't included in the latest amplify modules - please advise?

System:
OS: macOS 14.5
CPU: (12) arm64 Apple M2 Pro
Memory: 153.28 MB / 32.00 GB
Shell: /bin/zsh
Binaries:
Node: 20.9.0 - ~/.nvm/versions/node/v20.9.0/bin/node
Yarn: undefined - undefined
npm: 10.1.0 - ~/.nvm/versions/node/v20.9.0/bin/npm
pnpm: undefined - undefined
NPM Packages:
@aws-amplify/backend: 1.0.2
@aws-amplify/backend-cli: 1.0.3
aws-amplify: 6.3.3
aws-cdk: 2.140.0
aws-cdk-lib: 2.140.0
typescript: 5.4.5
AWS environment variables:
AWS_STS_REGIONAL_ENDPOINTS = regional
AWS_NODEJS_CONNECTION_REUSE_ENABLED = 1
AWS_SDK_LOAD_CONFIG = 1
No CDK environment variables