From @Jonarod on Sat Jul 22 2017 11:59:45 GMT+0000 (UTC)
Yeah I get the same response…
{ status: 403,
statusText: 'Forbidden',
data: { Message: 'User: arn:aws:sts::907468717626:assumed-role/Cognito_notesidentitypoolAuth_Role/CognitoIdentityCredentials is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:us-east-2:********7626:ux5xagukr9/prod/POST/notes' } }
I guess we forgot some tweaks that are not in the code, but rather in the aws console.
From @Jonarod on Sat Jul 22 2017 12:07:50 GMT+0000 (UTC)
Ok, I got it working.
Basically, I deleted my Federated Identity Pool and recreated it from scratch following this section:
http://serverless-stack.com/chapters/create-a-cognito-identity-pool.html
Note that after doing so, I got these messes:
After that, I got correct 200 status.
Hope it helps
From @mikhaelbendavid on Sat Jul 22 2017 15:01:21 GMT+0000 (UTC)
I’m not able to clear this test - if I put in all of my information in as a string, I get the cmd line response:
‘Authenticating with User Pool
User does not exist’
Which makes no sense, because the user definitely exists - I created one with the same default credentials as in the example and a seperate one, which I used to create, update, delete the event.json file throughout the tutorial.
When I remove all the semi-colons from the data, it runs through saying:
‘Authenticating with User Pool’
Getting temporary credential
Making API request
And then gives me the same JSON token error as the other commenter upstairs!
When I try just taking the string out the username and password, and keeping the rest of the strings there (and some variations) I get this error message:
Authenticating with UserPool
Getting temporary credentials
Inaccessible host: cognito-identity.xn--us-east-2-499dua.amazonaws.com'. This service may not be available in the‘us-east-2’’ region.
However, from looking at AWS documentation, Cognito Identity should be available in US-East-2… Halp!
From @jayair on Sat Jul 22 2017 19:06:47 GMT+0000 (UTC)
@tsdorsey I just tried your repo and I got it to deploy and call it fine. Of course the call failed because I don’t have the IAM roles set up properly to do this. But It’s calling everything fine.
I suspect there is something going on on your local. Can you try the following and check the versions you are running?
From @jayair on Sat Jul 22 2017 19:10:51 GMT+0000 (UTC)
@marshallbunch Are you seeing the same error as @tsdorsey? If you go into your CloudWatch logs do you see the same error (Unable to import module 'create': Error)?
From @jayair on Sat Jul 22 2017 19:11:46 GMT+0000 (UTC)
@Jonarod Yeah that error sounds like the IAM Role was not set properly. Thanks for reporting back with detail. I’m sure it’ll help folks that run into something similar.
From @jayair on Sat Jul 22 2017 19:16:36 GMT+0000 (UTC)
@navinkumarr Your issue sounds like the issue @Jonarod ran into. You can check if the IAM Role has been set properly by going to your AWS Console > IAM > Roles (in the sidebar) > Cognito_notesidentitypoolAuth_Role > Scroll down and click on Show Policy.
And make sure the policy looks like the one in the tutorial.
From @jayair on Sat Jul 22 2017 19:18:28 GMT+0000 (UTC)
@mikhaelbendavid Are you on Windows as well like @marshallbunch? Can I see the full command you used that generated that last error?
From @thesavvygreek on Sat Jul 22 2017 22:41:29 GMT+0000 (UTC)
@jayair I’m getting
{ status: 502,
statusText: 'Bad Gateway',
data: { message: 'Internal server error' } }
Digging deeper into Cloudwatch, specifically the create lambda function, I get
Unable to import module 'create': Error
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/var/task/create.js:76:18)
at __webpack_require__ (/var/task/create.js:20:30)
at Object.<anonymous> (/var/task/create.js:167:20)
at __webpack_require__ (/var/task/create.js:20:30)
at /var/task/create.js:63:18
at Object.<anonymous> (/var/task/create.js:66:10)
My package.json is:
{
"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": {
"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.0.0",
"webpack": "^3.3.0",
"webpack-node-externals": "^1.6.0"
},
"dependencies": {
"babel-runtime": "^6.23.0"
}
}
I haven’t done any digging into the packaging that serverless deploy produces but this is to confirm I’m experiencing the same issue as @tsdorsey is experiencing.
From @jayair on Sat Jul 22 2017 23:00:36 GMT+0000 (UTC)
@thesavvygreek Can I see what version of Node, NPM, and Serverless you are using?
From @thesavvygreek on Sat Jul 22 2017 23:08:58 GMT+0000 (UTC)
@jayair Sure
From @jayair on Sat Jul 22 2017 23:35:51 GMT+0000 (UTC)
@thesavvygreek @tsdorsey Thanks for that. Figured it out!
It’s a Serverless Framework bug. They broke it with their latest release. Here is the issue somebody else opened for it - https://github.com/serverless/serverless/issues/3972
For now you can use 1.17.0 by doing the following. I’ll add this to the tutorial.
$ npm uninstall -g serverless
$ npm install -g serverless@1.17.0
And then serverless deploy again.
From @jayair on Sat Jul 22 2017 23:38:59 GMT+0000 (UTC)
@thesavvygreek Btw, your package.json is missing this line for some reason - https://github.com/AnomalyInnovations/serverless-stack-demo-api/blob/master/package.json#L34
From @thesavvygreek on Sun Jul 23 2017 00:11:01 GMT+0000 (UTC)
@jayair Ah nice one, it works! Thanks for the help!
From @bradodarb on Sun Jul 23 2017 06:08:39 GMT+0000 (UTC)
I’m running into a 403 as well. I tried @Jonarod 's approach and carefully recreated the pool, but no dice.
I get this in the terminal:
Authenticating with User Pool Getting temporary credentials Making API request { status: 403, statusText: 'Forbidden', data: { message: 'Forbidden' } }
From @tsdorsey on Sun Jul 23 2017 08:08:04 GMT+0000 (UTC)
@jayair thank you so much for the thorough and quick help.
@marshallbunch did you get things squared away using this info?
I had a moment of horror when I moved to serverless@1.17.0 and it still failed. Then I got to thinking about it and realized that I was using an environment variable for the region in my dynamodb-lib file. When I hard coded that to be us-west-2 The test came back successful. I know aws-lambda can do environment variables but I’ll sort that out later.
For posterities sake I was running the following versions:
node -v 8.1.3
npm -v 5.0.3
serverless -v 1.18.0
From @jayair on Mon Jul 24 2017 01:14:50 GMT+0000 (UTC)
@bradodarb Can you take a look at your Cloudwatch logs to see what it says? Also, can you post the IAM policy that you have (follow these instructions https://github.com/AnomalyInnovations/serverless-stack-com/issues/112#issuecomment-317204545)?
From @bradodarb on Mon Jul 24 2017 15:48:01 GMT+0000 (UTC)
Thanks for taking a look, @jayair.
I enabled logging on the API stage but see nothing in cloudwatch.
I did triple check my setting as you suggested and confirm that I have this inline role:
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"mobileanalytics:PutEvents",
"cognito-sync:*",
"cognito-identity:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::m4-user-assets/${cognito-identity.amazonaws.com:sub}*"
]
},
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke"
],
"Resource": [
"arn:aws:execute-api:us-east-1:*:ps8mmgaj2c/*"
]
}
]
}
From @bradodarb on Mon Jul 24 2017 15:54:24 GMT+0000 (UTC)
I tried switching the test parameters up a bit and instead of breaking the test url up between invoke-url and path-template as in the example I used the invoke-uRL from the API Gateway console and set the template to ‘/’
So instead of this:
apig-test \
--username='admin@example.com' \
--password='Passw0rd!' \
--user-pool-id='us-east-1_***********' \
--app-client-id='*************************' \
--cognito-region='us-east-1' \
--identity-pool-id='us-east-1:******************************************' \
--invoke-url='https://ps8mmgaj2c.execute-api.us-east-1.amazonaws.com/dev' \
--api-gateway-region='us-east-1' \
--path-template='/mail' \
--method='POST' \
--body='{"content":"hello world","attachment":"hello.jpg"}
I tried this:
apig-test \
--username='admin@example.com' \
--password='Passw0rd!' \
--user-pool-id='us-east-1_***********' \
--app-client-id='*************************' \
--cognito-region='us-east-1' \
--identity-pool-id='us-east-1:******************************************' \
--invoke-url='https://ps8mmgaj2c.execute-api.us-east-1.amazonaws.com/dev/mail' \
--api-gateway-region='us-east-1' \
--path-template='/' \
--method='POST' \
--body='{"content":"hello world","attachment":"hello.jpg"}
And I seemed to get more information back:
Authenticating with User Pool
Getting temporary credentials
Making API request
{ 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\'POST\n/dev/mailC%3A/Program%2520Files/Git/\n\naccept:application/json\ncontent-type:application/json\nhost:ps8mmgaj2c.execute-api.us-east-1.amazonaws.com\nx-amz-date:2017
0724T154352Z\n\naccept;content-type;host;x-amz-date\n3a99f7c41ea871222ce9eb05cc8c7a5bbfc8e141bbb3c3999cff381d1462d448\'\n\nThe String-to-Sign should have been\n\'AWS4-HMAC-SHA256\n20170724T154352Z\n20170724/us-east-
1/execute-api/aws4_request\nb85c01d15750e6db44ea387c0ac4dec6bfd39b6cd8a245e32141e97b82955917\'\n' } }
This prompted me to have a look at all settings in the test parameters and everything validated to be using the correct variables.
From @jayair on Mon Jul 24 2017 18:12:19 GMT+0000 (UTC)
@bradodarb The IAM Policy looks good. Can you post your serverless.yml as well? Let’s make sure things look okay.