sst / guide

Repo for guide.sst.dev
https://guide.sst.dev
MIT License
3.68k stars 444 forks source link

Comments: Test the APIs #112

Closed jayair closed 6 years ago

jayair commented 7 years ago

Link to chapter - http://serverless-stack.com/chapters/test-the-apis.html

michaelcuneo commented 7 years ago

When I log my apig-test in both the HTML request logging, and API request logging, I get no errors in the actual API Log, but in the HTML log I get ...

AccessDeniedException: User: arn:aws:sts::481588845003:assumed-role/hrs-admin-api-prod-ap-southeast-2-lambdaRole/hrs-admin-api-prod-create is not authorized to perform: dynamodb:PutItem on resource: arn:aws:dynamodb:ap-southeast-2:481588845003:table/notes

But the calls work fine from two chapters ago. I can create, update, edit, delete, etc... But I can't do it authorised from the apig_test. :(

jayair commented 7 years ago

@michaelcuneo That should be easy to fix. Can I see your serverless.yml?

In the past chapters we were invoking it directly using your local credentials. The apig-test is mocking how a user will be accessing it.

michaelcuneo commented 7 years ago

My serverless.yml is identical to the one as per the tutorial...

http://mcuneo.webhop.me/misc/serverless.yml

michaelcuneo commented 7 years ago

I did actually run through a bunch of issues that it could have been, I've added AWSLambdaRole and AmazonDynamoDBFullAccess permission to the Admin user I've created, but it didn't help. I'm using all the correct keys and secrets for that admin user, everything works 100% without auth, but fails with auth. Baffled. I've been on this issue for hours.

jayair commented 7 years ago

@michaelcuneo Yeah the issue is in your serverless.yml in this line.

Resource: "arn:aws:dynamodb:ap-southeast-2a:*:*"

It should be.

Resource: "arn:aws:dynamodb:ap-southeast-2:*:*"

You can see this in the error "...on resource: arn:aws:dynamodb:ap-southeast-2:481588845003:table/notes". It's looking for the table in the region ap-southeast-2.

michaelcuneo commented 7 years ago

Damn! It is too! I always forget that. Cause ap-southeast-2 has an a and b, but they both go to just 2.

Thanks! Works perfect now.

pjamieson commented 7 years ago

On a Mac w/serverless v1.19.0 I initially received the following output after running the apig-test command with good parameters:

Authenticating with User Pool Getting temporary credentials Invalid identity pool configuration. Check assigned IAM roles for this pool.

I confirmed I'd followed the Identity Pool instructs correctly, but noticed Authenticated and Unauthenticated roles had not been attached to my Identity Pool. After selected the Auth_Role from the Edit identity pool dropdown and creating a new Unauth_Role (just accepting the default policy json), and saving the changes, the same apig-test command worked as expected.

Did I miss something in the instructions, or are additional instructions needed?

jayair commented 7 years ago

@pjamieson You should not have to do that. It should be attached. I wonder if it didn't get saved properly the first time around. How did you find out that they weren't attached? Can you show me a screenshot? Thanks.

pjamieson commented 7 years ago

@jayair You are correct; it apparently was not saved correctly. I deleted my initial Identity Pool and the two associated IAM Roles, recreated the Identity Pool as per the instructions, and the roles are there as they should be. And the apig-test works as it should, too. All with serverless 1.19.0. Thanks! (Great turorial. I'm back after having done the prior version about two months ago. Thanks for pointing the way to Identity Pools.)

pjamieson commented 7 years ago

BTW, it seems that an apostrophe character (') in the content string breaks the apig-test command execution. (Just an FYI; I'm just removing it.) I see it's due to the body being enclosed in single quotes.

jayair commented 7 years ago

@pjamieson Thanks for reporting on 1.19.0. Just removed the 1.17.0 restriction.

gregt590 commented 7 years ago

I had the same apig-test error as @tsdorsey and deepseafishing above: Authenticating with User Pool Getting temporary credentials Making API request { status: 500, statusText: 'Internal Server Error', data: { status: false } }

with the following error being reported in CloudWatch: message: 'User: arn:aws:sts::386757086157:assumed-role/notes-app-api-prod-us-west-2-lambdaRole/notes-app-api-prod-create is not authorized to perform: dynamodb:PutItem on resource: arn:aws:dynamodb:us-west-2:386757086157:table/notes', code: 'AccessDeniedException', time: 2017-08-11T03:03:28.333Z, statusCode: 400,

It did turn out to be caused by the indentation in the serverless.yml file where the iamRoleStatements: were also indented at the same level as provider: instead of one level lower and therefore got ignored without error.

Properly indenting that section with tabs fixed the problem and apig-test now successfully reported: Authenticating with User Pool Getting temporary credentials Making API request { status: 200, statusText: 'OK', data: { userId: 'us-west-2:c25c8604-477a-4eeb-921f-dcb2ea30ebe9', noteId: '66f305b0-7e47-11e7-81ba-45b2b0dbb6ab', content: 'hello world', attachment: 'hello.jpg', createdAt: 1502423079307 } }

running on Mac OS X 10.12.6 with: node v6.11.1 npm 3.10.10 aws-sdk 2.95.0 webpack 3.5.3 serverless 1.19.0

Thanks you for this tutorial.

jayair commented 7 years ago

Thanks for reporting back @gregt590. The indenting issues causes a lot of headaches for folks.

jeffxie888 commented 7 years ago

PLEASE HELP!! I have read through the tutorial very carefully and have been struggling over this for so long.

Authenticating with User Pool
Getting temporary credentials
Making API request
{ status: 403,
  statusText: 'Forbidden',
  data: '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">\n<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">\n<TITLE>ERROR: The request could not be satisfied</TITLE>\n</HEAD><BODY>\n<H1>ERROR</H1>\n<H2>The request could not be satisfied.</H2>\n<HR noshade size="1px">\nBad request.\n<BR clear="all">\n<HR noshade size="1px">\n<PRE>\nGenerated by cloudfront (CloudFront)\nRequest ID: 21E5qKTlLx8RJytknBwPbE9kFWg3CNUxFLD_N3xMhAhO7BpxiTzKhg==\n</PRE>\n<ADDRESS>\n</ADDRESS>\n</BODY></HTML>' }
jayair commented 7 years ago

@jeffxie888 It looks like we might be hitting the wrong URL? Can I see the full apid-test command?

Cotel commented 7 years ago

I get 403 Bad Signature response too in various of my endpoints. I've tried to put the whole URL in invoke_url and it didn't help me:

{ status: 403,
  statusText: 'Forbidden',
  data: { message: 'The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.\n\nThe Canonical String for this request should have been\n\'GET\n/dev/feed\npage=0&page_size=10\naccept:application/json\nhost:wex1vzo67b.execute-api.us-east-1.amazonaws.com\nx-amz-date:20170814T172052Z\n\naccept;host;x-amz-date\ne3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\'\n\nThe String-to-Sign should have been\n\'AWS4-HMAC-SHA256\n20170814T172052Z\n20170814/us-east-1/execute-api/aws4_request\nb53eba78268cf91932fa865871dd575a129681dcd4d3a9e79a676034efa1c419\'\n' } }

However, I may have found a pattern. I created a new service and started deploying each endpoint separately so I could find the reason of fails:

I tried to transform special characters into URL valid characters and still didn't work. Then I tried to search for testtest.com and I got a 404 as expected. And feed without page information returns 500 as expected too.

I'm currently moving all that information to body in requests, but that forces me to only use POST as requests method.

Is there a way to use special characters in URLs and don't getting 403 Bad Signature as response?

Thank you and thank you for this awesome tutorial šŸ‘

jayair commented 7 years ago

@Cotel Thanks for details.

Case 3 & 4 contain querystring parameters that need to be passed in as an object into the additional-params option ({page:0,page_size:10}). For case 2, since we need the email part encoded we can send that in as a part of the params as well. So it could look like /users/email/{emailId} and the params option would be {emailId:"test@test.com"}. Give that a try and let me know how that goes.

For apig-test we internally use the https://github.com/kndt84/aws-api-gateway-client, and they have an example on how to use these options as well. We could work on making this more user friendly though.

Cotel commented 7 years ago

I just tried to replace the params and now it is working as expected! Thank you šŸ’Æ

jayair commented 7 years ago

@Cotel šŸ‘Œ

Once you get to the frontend portion you would need to do something similar. Let me know how that goes.

Cotel commented 7 years ago

I'm now making the react part and it returns the same error as when testing with the cli tool:

export const getDatabaseUser = (email, userToken) =>
    invokeApig({
        path: `/users/email/${email}`
    }, userToken)

I am sure the userToken is arriving correctly to this method. Configuration is set properly and the IAM role simulation allows me to invoke the Api. awsLib.js and sigv4Client.js is copy paste from the tutorial...

image

The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.The Canonical String for this request should have been'GET/dev/users/email/test%40test.comaccept:application/jsonā†µhost:wex1vzo67b.execute-api.us-east-1.amazonaws.comx-amz-date:20170817T183520Zaccept;host;x-amz-datee3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'The String-to-Sign should have been'AWS4-HMAC-SHA25620170817T183520Z20170817/us-east-1/execute-api/aws4_request57959ea0b29bcb252d83b38d563e3b3e67684f8eba45439fdf1f4ea21f69f856'"
everrr1025 commented 7 years ago

in windows command line, should remove all double quotes, like --username=myname for the value in json format, it should be look like this: --body="{\"content\":\"hello world\", \"attachment\":\"dog.jpg\"}"

jayair commented 7 years ago

@everrr1025 Thanks for letting us know. I'm thinking of putting together a separate chapter on the differences for Windows.

jayair commented 7 years ago

@Cotel I thought I had replied to your comment but I think I must have not sent it.

The email that you are passing in as a part of the path needs to be URL encoded. Instead of test@test.com, it needs to be test%40test.com. You can do this by hand or your can use something like https://github.com/bramstein/url-template.

Spartano commented 7 years ago

i am on windows and i get 403 forbidden, i have readed all comments until the end, installed version 1.17 , copy pasted the yml file, changed ' with ", on my local machine i can invoke the functions, on the IAM simulator i can invoke the Amazon API Gateway, but the apig-test still doesnt work for me.

Is this test necesary to continue the rest of the tutorial? can i continue even if apig-test failed?

jayair commented 7 years ago

@Spartano Can I see the full command and the error message you are seeing? If it doesn't work here it most likely won't work down the road.

Spartano commented 7 years ago

@jayair

apig-test --username admin@example.com --password Passw0rd! --user-pool-id eu-west-1_xxxx --app-client-id 5baajsxxxxx --cognito-reg
ion eu-west-1 --identity-pool-id eu-west-1:bxxxxxx4-ad01-9e72a51c2b0f --invoke-url https://rxxxxxxni.execute-api.eu-west-1.amazonaws.com/prod
--api-gateway-region eu-west-1 --path-template notes --method POST --body "{\"content\":\"hello world\",\"attachment\":\"hello.jpg\"}"
Authenticating with User Pool
Getting temporary credentials
Making API request
{ status: 403,
  statusText: 'Forbidden',
  data: { message: 'Forbidden' } }

package.json

{
  "name": "notes-app-api",
  "version": "1.0.0",
  "description": "",
  "main": "handler.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "aws-sdk": "^2.95.0",
    "babel-core": "^6.25.0",
    "babel-loader": "^7.1.1",
    "babel-plugin-transform-runtime": "^6.23.0",
    "babel-preset-es2015": "^6.24.1",
    "babel-preset-stage-3": "^6.24.1",
    "glob": "^7.1.2",
    "serverless-webpack": "^2.2.0",
    "webpack": "^3.5.2",
    "webpack-node-externals": "^1.6.0"
  },
  "dependencies": {
    "babel-runtime": "^6.25.0",
    "uuid": "^3.1.0"
  }
}

What are the steps that one could make to debug this problem? When i created the From my point of view id love to see a extra tutorial on debugging the API calls, like the IAM Simulator and enabling CloudWatch Logs and how to use them.

jayair commented 7 years ago

@Spartano Yeah a debugging related chapter is definitely on our list.

So far what you posted looks good. But you'd generally start by looking at your CloudWatch logs to see where the 403 is being returned. Let me know if you've done that already.

Also, double checking your serverless.yml. So if you could post that as well.

Spartano commented 7 years ago

@jayair so, to wrap up, i can invoke the functions from my local development, and in my CloudWatch i dont get any error, it seems like the calls never get to the cloud.

service: reviso-time-tracking

# Use serverless-webpack plugin to transpile ES6/ES7
plugins:
  - serverless-webpack

# Enable auto-packing of external modules
custom:
  webpackIncludeModules: true

provider:
  name: aws
  runtime: nodejs6.10
  stage: prod
  region: eu-west-1

  # 'iAmRoleStatement' defines permission policy for Lambda function
  # We are granting Lambda functions permission to access Dynamo DB
  iAmRoleStatement:
   - Effect: Allow
     Action:
       - dynamodb:DescribeTable
       - dynamodb:Query
       - dynamodb:Scan
       - dynamodb:GetItem
       - dynamodb:PutItem
       - dynamodb:UpdateItem
       - dynamodb:DeleteItem
     Resource: "arn:aws:dynamodb:eu-west-1:*:*"

functions:
  #Defines an HTTP API endpoint that calls the main function in create.js
  # - path: rul path is /notes
  # - method: POST request
  # - cors: enabled CORS for browser cross domain API calls
  # - authorizer: authenticate using the AWS IAM role
  create:
    handler: create.main
    events:
      - http:
          path: notes
          method: post
          cors: true
          authorizer: aws_iam

  get:
    #Defines HTTP API endoing that calls main function in get.js
    # - path: url path is /notes/{id}
    # - method: GET request
    handler: get.main
    events:
      - http:
          path: notes/{id}
          method: get
          cors: true
          authorizer: aws_iam

  list:
     handler: list.main
     events:
       - http:
          path: notes
          method: get
          cors: true
          authorizer: aws_iam

  update:
     handler: update.main
     events:
       - http:
          path: notes/{id}
          method: put
          cors: true
          authorizer: aws_iam

  delete:
     handler: delete.main
     events:
       - http:
          path: notes/{id}
          method: delete
          cors: true
          authorizer: aws_iam                 
jayair commented 7 years ago

@Spartano That also looks okay. I think the 403 is coming from API Gateway. API Gateway logs are not on by default and are a little trickier to turn on. Can you try this - https://kennbrodhagen.net/2016/07/23/how-to-enable-logging-for-api-gateway/ and see if you get something in the logs?

Spartano commented 7 years ago

@jayair i am making some progress, the problem was in the syntax of the apig code, since i am on windows. I am using Visual Code and i have bash integrated, so i have wrongly presumed that i could use the same syntax. When i changed terminal, i was finaly able to see the errors inside the terminal and in the cloud watch.

in one of the above comments there is a command for windows, but the problem was it was missing some empty spaces. The correct command that worked for me was this: apig-test --username admin@example.com --password Passw0rd! --user-pool-id eu-west-1_pxxxxGN --app-client-id 5bxxxxxg29iudh93 --cognito-region eu-west-1 --identity-pool-id eu-west-1:398cxxxxxx9adf1037 --invoke-url https://vxxxxvj.execute-api.eu-west-1.amazonaws.com/prod/ --api-gateway-region eu-west-1 --path-template notes --method POST --body "{\"content\":\"hello world\",\"attachment\":\"hello.jpg\"}"

now i am getting is not authorized to perform: dynamodb:PutItem on resource: arn:aws:dynamodb:eu-west-1

it will be really nice a guide on how to test it with Postman or another service, so it doenst matter what OS you are using.

jayair commented 7 years ago

@Spartano That makes sense. Thanks for trying to debug it more.

I just noticed that there is a typo in your serverless.yml. It should say iamRoleStatements instead of iamRoleStatement; like so https://github.com/AnomalyInnovations/serverless-stack-demo-api/blob/master/serverless.yml#L17.

SeanSilke commented 7 years ago

Have this problem with status: 500:

 Authenticating with User Pool
 Getting temporary credentials
 Making API request
 { status: 500,
  statusText: 'Internal Server Error',
  data: { status: false } }

The problem was in serverless.yml fiile under the line Resource: "arn:aws:dynamodb:us-west-2:*:*" The was the wrong region because I don't change it from the example's one. When I change region i receive

{ status: 200,
  statusText: 'OK',
  data:
   { userId: 'us-west-2:adb2febb-8fae-4745-98b6-4481cb8655d1',
     noteId: 'f1962400-89a4-11e7-8c05-5928f46acd0b',
     content: 'hello world',
     attachment: 'hello.jpg',
     createdAt: 1503672717889 } } 

I also downgrade the serverless as was mentioned in previous comments.

@jayair Please add part in tutorial on proper region settings. I came across this problem in earlier chapters but was able to notice it. This one with api deploying gave me some pain.

jayair commented 7 years ago

@SeanSilke Thanks for reporting back. Yeah I'll add a note in the parts that need a region change.

zacacollier commented 7 years ago

I was experiencing the same errors as @tsdorsey and @thesavvygreek - 502 Bad Gateway and Unable to import module 'create': Error being reported in the CloudWatch logs.

fixed it by:

  1. downgrading to serverless 1.17.0 as @jayair suggested
  2. used the Roles Simulator to verify that serverless IAM roles were configured properly
  3. Enabling CloudWatch logging, discovered Unable to import module error
  4. Found this comment on a similar issue reported to serverless-webpack

tldr; check your package.json and ensure that babel-runtime is listed under dependencies. If it isn't, yarn add babel-runtime and redeploy serverless

also, per the linked issue's discussion thread, make sure that

custom:
  webpackIncludeModules: true

is included in your serverless.yml (it should be if you configured serverless as described in the tutorial)

jayair commented 7 years ago

@zacacollier Thanks for the really detailed report back. I'm working on a chapter for debugging and your feedback will help with that.

bumblebeen commented 7 years ago

@zacacollier You don't need to downgrade to serverless 1.17.0. I am using 1.21.0 and it works just by adding babel-runtime in dependencies. Great find man. thanks

jayair commented 7 years ago

@bumblebeen Yeah if I recall, it was 1.18 that was giving folks problems.

paolini commented 7 years ago

When running apig-test I get the following error:

Authenticating with User Pool
/usr/local/lib/node_modules/aws-api-gateway-cli-test/node_modules/aws-sdk/lib/request.js:31
            throw err;
            ^

TypeError: callback.newPasswordRequired is not a function
    at /usr/local/lib/node_modules/aws-api-gateway-cli-test/node_modules/amazon-cognito-identity-js/lib/CognitoUser.js:281:27
    at Response.<anonymous> (/usr/local/lib/node_modules/aws-api-gateway-cli-test/node_modules/amazon-cognito-identity-js/lib/CognitoUser.js:249:18)
    at Request.<anonymous> (/usr/local/lib/node_modules/aws-api-gateway-cli-test/node_modules/aws-sdk/lib/request.js:364:18)
    at Request.callListeners (/usr/local/lib/node_modules/aws-api-gateway-cli-test/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/usr/local/lib/node_modules/aws-api-gateway-cli-test/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/usr/local/lib/node_modules/aws-api-gateway-cli-test/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/usr/local/lib/node_modules/aws-api-gateway-cli-test/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/usr/local/lib/node_modules/aws-api-gateway-cli-test/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /usr/local/lib/node_modules/aws-api-gateway-cli-test/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/usr/local/lib/node_modules/aws-api-gateway-cli-test/node_modules/aws-sdk/lib/request.js:38:9)
jayair commented 7 years ago

@paolini It looks like you might have created this user through the AWS Console? In this case the user is required to set a password when they first login. The apig-test CLI does not handle this case and expects that the user credentials are valid and can be used.

paolini commented 7 years ago

Yes thanks, that's the case... Seems there is no way to change or confirm the password from the aws console.

paolini commented 7 years ago

My next issue: IdentityPool not found.

I checked that the identityPoolId is correct:

$ aws cognito-identity list-identity-pools --max-results 10
{
    "IdentityPools": [
        {
            "IdentityPoolName": "notes identity pool",
            "IdentityPoolId": "eu-central-1:554ec0d7-0cd3-41e5-b5f9-cad20d34XXXX"
        }
    ]
}
$ apig-test --username=pippo --password=password --user-pool-id=eu-central-1_3w4UEXXXX --app-client-id 267es0fnrdurq91phh2afnXXXX congnito-region eu-central-1 --identity-pool-id eu-central-1:554ec0d7-0cd3-41e5-b5f9-cad20d34XXXX --invoke-url https://9goegkXXXX.execute-api.eu-central-1.amazonaws.com/prod --path-template notes --method POST --body {"content":"hello world"}
Authenticating with User Pool
Getting temporary credentials
IdentityPool 'eu-central-1:554ec0d7-0cd3-41e5-b5f9-cad20d34XXXX' not found.
jayair commented 7 years ago

@paolini Just glancing at your command. Shouldn't the congnito-region should be --congnito-region?

paolini commented 7 years ago

Thanks again. You are right! Now I reduced my problem to 403 Forbidden... :-(

u8006082 commented 7 years ago

I tried everything that I can and could not find anything wrong. the serverless.yml is same as posted here. but when I am test, I always got 403 error. it is running on Windows 7 and below is the output.

apig-test .............................
Authenticating with User Pool
Getting temporary credentials
Making API request
{ status: 403,
  statusText: 'Forbidden',
  data: { message: 'Forbidden' } }

D:\app-api>serverless -v
1.17.0

D:\app-api>npm -v
5.4.0

D:\app-api>node -v
v6.11.2
jayair commented 7 years ago

@u8006082 If you are on Windows, @Spartano's comment https://github.com/AnomalyInnovations/serverless-stack-com/issues/112#issuecomment-324556718 from above might help you. I think he was having the 403 error before as well.

@paolini @u8006082 Another thing to make sure to try is the IAM policy simulator - https://github.com/AnomalyInnovations/serverless-stack-com/issues/112#issuecomment-317821887.

u8006082 commented 7 years ago

Thanks Jayair! I missed "/" after prod. it should be https://hyuzdjsm1e.execute-api.us-east-1.amazonaws.com/prod/

by the way for window user you can use ^ (unix is ) to separate the line.

samxi commented 7 years ago

I am running the following command and getting an error: apig-test \ --username='admin@example.com' \ --password='Passw0rd!' \ --user-pool-id='us-west-2_*********' \ --app-client-id='*****************************' \ --cognito-region=ā€˜us-west-2ā€™ \ --identity-pool-id='us-west-2:***************************************' \ --invoke-url='https://***********.execute-api.us-west-2.amazonaws.com/prod' \ --api-gateway-region=ā€˜us-west-2ā€™ \ --path-template='/notes' \ --method='POST' \ --body='{"content":"hello world","attachment":"hello.jpg"}'

Error: Inaccessible host:cognito-identity.xn--us-west-2-**.amazonaws.com'. This service may not be available in the ā€˜us-west-2ā€™' region.

I've done some searching on this and am not finding a solution. Anybody familiar with this issue?

jayair commented 7 years ago

@samxi Hmmm that seems strange. The only thing I can think of here is to double check the Cognito id's that are being set and make sure that the region info for them is correct.

Spartano commented 7 years ago

@samxi there is no space after each comand correct: "apig-test/space" not vorrect:"apig-testspace/space"

samxi commented 7 years ago

@jayair @Spartano

I removed the space before \ on my invoke command and got a new error: Authenticating with User Pool Getting temporary credentials Making API request { status: 403, statusText: 'Forbidden', data: { Message: 'User: arn:aws:sts::904892619278:assumed-role/Cognito_notesidentitypoolAuth_Role/CognitoIdentityCredentials is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:us-west-2:********9278:zgbqusr8ua/prod/POST/notes' } }

I tried @Jonarod 's suggestion and deleted my initial identity and created a new identity. Now I am getting a 500 error: {Ā status:Ā 500, Ā Ā statusText:Ā 'InternalĀ ServerĀ Error', Ā Ā data:Ā {Ā status:Ā falseĀ }Ā }

The command I am using was updated to the new identity ID: apig-test --username='admin@example.com' --password='Passw0rd!' --user-pool-id='us-west-2_XOwARY4ea' --app-client-id='6k30s80bm1agn9c1pbjdhnn1p3' --cognito-region='us-west-2' --identity-pool-id='us-west-2:b1a93438-17a6-4c6c-91a2-31b4883da2a8' - -invoke-url='https://zgbqusr8ua.execute-api.us-west-2.amazonaws.com/prod' --api-gateway-region='us-west-2' --path-template='/notes' --method='POST' --body='{"content":"hello world","attachment":"hello.jpg"}'

My Auth_Role policy for the role in IAM is: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "mobileanalytics:PutEvents", "cognito-sync:*", "cognito-identity:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "s3:*" ], "Resource": [ "arn:aws:s3:::sambb-notes-app-uploads/${cognito-identity.amazonaws.com:sub}*" ] }, { "Effect": "Allow", "Action": [ "execute-api:Invoke" ], "Resource": [ "arn:aws:execute-api:us-west-2:*:zgbqusr8ua/*" ] } ] }

Not sure what else I am missing. I set up a new role for CloudWatch logging but am not sure how that works.