Unable to determine service/operation name to be authorized when using API Gateway to POST to SQS
Following the accepted answer here, I tried to configure an API Gateway to send messages to SQS using POST instead of GET (I was able to make GET work). When using POST, I get this response:
<AccessDeniedException>
<Message>Unable to determine service/operation name to be authorized</Message>
</AccessDeniedException>
This is how my mapping template is configured
#set($clientKey = $input.params('clientkey'))
#set($url = "https://sqs.us-east-2.amazonaws.com/XXXXXXXX/SomeQueuePrefix-${clientKey}-SomeQueueEnvironment.fifo")
Action=SendMessage##
&QueueUrl=$util.urlEncode($url)##
&MessageGroupId=$input.params('messageGroupId')##
&MessageDeduplicationId=1##
&MessageBody=$util.urlEncode($input.body)
It looks like it maps the body correctly
Wed Nov 14 20:39:44 UTC 2018 : Endpoint request body after transformations: Action=SendMessage&QueueUrl=https%3A%2F%2Fsqs.us-east-2.amazonaws.com%2FXXXXXXXXX%2FSomeQueuePrefix-TEST-SomeQueueEnvironment.fifo&MessageGroupId=3&MessageDeduplicationId=1&MessageBody=%7B%0A++++%22configurationId%22%3A+1%0A%7D
Wed Nov 14 20:39:44 UTC 2018 : Sending request to https://sqs.us-east-1.amazonaws.com//
Screenshot of my Integration Request setup
My IAM policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": [
"arn:aws:sqs:us-east-1:XXXXXXXXX:CADAUTO-*-DEV.fifo"
],
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage",
"sqs:DeleteMessage"
]
}
]
}
Can anybody see why this isn't working?
amazon-web-services aws-api-gateway amazon-sqs
add a comment |
Following the accepted answer here, I tried to configure an API Gateway to send messages to SQS using POST instead of GET (I was able to make GET work). When using POST, I get this response:
<AccessDeniedException>
<Message>Unable to determine service/operation name to be authorized</Message>
</AccessDeniedException>
This is how my mapping template is configured
#set($clientKey = $input.params('clientkey'))
#set($url = "https://sqs.us-east-2.amazonaws.com/XXXXXXXX/SomeQueuePrefix-${clientKey}-SomeQueueEnvironment.fifo")
Action=SendMessage##
&QueueUrl=$util.urlEncode($url)##
&MessageGroupId=$input.params('messageGroupId')##
&MessageDeduplicationId=1##
&MessageBody=$util.urlEncode($input.body)
It looks like it maps the body correctly
Wed Nov 14 20:39:44 UTC 2018 : Endpoint request body after transformations: Action=SendMessage&QueueUrl=https%3A%2F%2Fsqs.us-east-2.amazonaws.com%2FXXXXXXXXX%2FSomeQueuePrefix-TEST-SomeQueueEnvironment.fifo&MessageGroupId=3&MessageDeduplicationId=1&MessageBody=%7B%0A++++%22configurationId%22%3A+1%0A%7D
Wed Nov 14 20:39:44 UTC 2018 : Sending request to https://sqs.us-east-1.amazonaws.com//
Screenshot of my Integration Request setup
My IAM policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": [
"arn:aws:sqs:us-east-1:XXXXXXXXX:CADAUTO-*-DEV.fifo"
],
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage",
"sqs:DeleteMessage"
]
}
]
}
Can anybody see why this isn't working?
amazon-web-services aws-api-gateway amazon-sqs
Verify that in the Integration Request, the HTTP Method is set toPOST
.
– Michael - sqlbot
Nov 14 '18 at 23:53
Thanks. I posted a screenshot of my Integration Request. HTTP method is set to POST; does everything else look okay?
– Eric Wood
Nov 15 '18 at 15:39
I don't think defining the path parameter in the integration request is doing what you intend, and that might be problematic, though I could be mistaken. It is also possible that the service is getting confused by the lack of##
at the end of the first two lines of your template. I feel like whatever is causing this is going to be something relatively minor-seeming/subtle/non-obvious.
– Michael - sqlbot
Nov 15 '18 at 16:54
The path parameter is getting substituted correctly, as I can see the request is sent with the expected body (clientKey is 'TEST' in this example, and you can see that in the value of the QueueUrl parameter in the request body. I wondered about the double slash in the request url, but if I take / out of the path override, the request fails. I noticed that my region in the body is us-east-2 and our queue is in us-east-1. I thought I had found the forehead-slappingly obvious reason for the error. But after I changed it to us-east-1 I still get the same issue.
– Eric Wood
Nov 15 '18 at 17:59
I added my policy in case there is anything in there. I tried hardcoding 'TEST' as well as using '*" for resources, but neither had any effect.
– Eric Wood
Nov 15 '18 at 18:47
add a comment |
Following the accepted answer here, I tried to configure an API Gateway to send messages to SQS using POST instead of GET (I was able to make GET work). When using POST, I get this response:
<AccessDeniedException>
<Message>Unable to determine service/operation name to be authorized</Message>
</AccessDeniedException>
This is how my mapping template is configured
#set($clientKey = $input.params('clientkey'))
#set($url = "https://sqs.us-east-2.amazonaws.com/XXXXXXXX/SomeQueuePrefix-${clientKey}-SomeQueueEnvironment.fifo")
Action=SendMessage##
&QueueUrl=$util.urlEncode($url)##
&MessageGroupId=$input.params('messageGroupId')##
&MessageDeduplicationId=1##
&MessageBody=$util.urlEncode($input.body)
It looks like it maps the body correctly
Wed Nov 14 20:39:44 UTC 2018 : Endpoint request body after transformations: Action=SendMessage&QueueUrl=https%3A%2F%2Fsqs.us-east-2.amazonaws.com%2FXXXXXXXXX%2FSomeQueuePrefix-TEST-SomeQueueEnvironment.fifo&MessageGroupId=3&MessageDeduplicationId=1&MessageBody=%7B%0A++++%22configurationId%22%3A+1%0A%7D
Wed Nov 14 20:39:44 UTC 2018 : Sending request to https://sqs.us-east-1.amazonaws.com//
Screenshot of my Integration Request setup
My IAM policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": [
"arn:aws:sqs:us-east-1:XXXXXXXXX:CADAUTO-*-DEV.fifo"
],
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage",
"sqs:DeleteMessage"
]
}
]
}
Can anybody see why this isn't working?
amazon-web-services aws-api-gateway amazon-sqs
Following the accepted answer here, I tried to configure an API Gateway to send messages to SQS using POST instead of GET (I was able to make GET work). When using POST, I get this response:
<AccessDeniedException>
<Message>Unable to determine service/operation name to be authorized</Message>
</AccessDeniedException>
This is how my mapping template is configured
#set($clientKey = $input.params('clientkey'))
#set($url = "https://sqs.us-east-2.amazonaws.com/XXXXXXXX/SomeQueuePrefix-${clientKey}-SomeQueueEnvironment.fifo")
Action=SendMessage##
&QueueUrl=$util.urlEncode($url)##
&MessageGroupId=$input.params('messageGroupId')##
&MessageDeduplicationId=1##
&MessageBody=$util.urlEncode($input.body)
It looks like it maps the body correctly
Wed Nov 14 20:39:44 UTC 2018 : Endpoint request body after transformations: Action=SendMessage&QueueUrl=https%3A%2F%2Fsqs.us-east-2.amazonaws.com%2FXXXXXXXXX%2FSomeQueuePrefix-TEST-SomeQueueEnvironment.fifo&MessageGroupId=3&MessageDeduplicationId=1&MessageBody=%7B%0A++++%22configurationId%22%3A+1%0A%7D
Wed Nov 14 20:39:44 UTC 2018 : Sending request to https://sqs.us-east-1.amazonaws.com//
Screenshot of my Integration Request setup
My IAM policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": [
"arn:aws:sqs:us-east-1:XXXXXXXXX:CADAUTO-*-DEV.fifo"
],
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage",
"sqs:DeleteMessage"
]
}
]
}
Can anybody see why this isn't working?
amazon-web-services aws-api-gateway amazon-sqs
amazon-web-services aws-api-gateway amazon-sqs
edited Nov 15 '18 at 18:46
Eric Wood
asked Nov 14 '18 at 21:01
Eric WoodEric Wood
12
12
Verify that in the Integration Request, the HTTP Method is set toPOST
.
– Michael - sqlbot
Nov 14 '18 at 23:53
Thanks. I posted a screenshot of my Integration Request. HTTP method is set to POST; does everything else look okay?
– Eric Wood
Nov 15 '18 at 15:39
I don't think defining the path parameter in the integration request is doing what you intend, and that might be problematic, though I could be mistaken. It is also possible that the service is getting confused by the lack of##
at the end of the first two lines of your template. I feel like whatever is causing this is going to be something relatively minor-seeming/subtle/non-obvious.
– Michael - sqlbot
Nov 15 '18 at 16:54
The path parameter is getting substituted correctly, as I can see the request is sent with the expected body (clientKey is 'TEST' in this example, and you can see that in the value of the QueueUrl parameter in the request body. I wondered about the double slash in the request url, but if I take / out of the path override, the request fails. I noticed that my region in the body is us-east-2 and our queue is in us-east-1. I thought I had found the forehead-slappingly obvious reason for the error. But after I changed it to us-east-1 I still get the same issue.
– Eric Wood
Nov 15 '18 at 17:59
I added my policy in case there is anything in there. I tried hardcoding 'TEST' as well as using '*" for resources, but neither had any effect.
– Eric Wood
Nov 15 '18 at 18:47
add a comment |
Verify that in the Integration Request, the HTTP Method is set toPOST
.
– Michael - sqlbot
Nov 14 '18 at 23:53
Thanks. I posted a screenshot of my Integration Request. HTTP method is set to POST; does everything else look okay?
– Eric Wood
Nov 15 '18 at 15:39
I don't think defining the path parameter in the integration request is doing what you intend, and that might be problematic, though I could be mistaken. It is also possible that the service is getting confused by the lack of##
at the end of the first two lines of your template. I feel like whatever is causing this is going to be something relatively minor-seeming/subtle/non-obvious.
– Michael - sqlbot
Nov 15 '18 at 16:54
The path parameter is getting substituted correctly, as I can see the request is sent with the expected body (clientKey is 'TEST' in this example, and you can see that in the value of the QueueUrl parameter in the request body. I wondered about the double slash in the request url, but if I take / out of the path override, the request fails. I noticed that my region in the body is us-east-2 and our queue is in us-east-1. I thought I had found the forehead-slappingly obvious reason for the error. But after I changed it to us-east-1 I still get the same issue.
– Eric Wood
Nov 15 '18 at 17:59
I added my policy in case there is anything in there. I tried hardcoding 'TEST' as well as using '*" for resources, but neither had any effect.
– Eric Wood
Nov 15 '18 at 18:47
Verify that in the Integration Request, the HTTP Method is set to
POST
.– Michael - sqlbot
Nov 14 '18 at 23:53
Verify that in the Integration Request, the HTTP Method is set to
POST
.– Michael - sqlbot
Nov 14 '18 at 23:53
Thanks. I posted a screenshot of my Integration Request. HTTP method is set to POST; does everything else look okay?
– Eric Wood
Nov 15 '18 at 15:39
Thanks. I posted a screenshot of my Integration Request. HTTP method is set to POST; does everything else look okay?
– Eric Wood
Nov 15 '18 at 15:39
I don't think defining the path parameter in the integration request is doing what you intend, and that might be problematic, though I could be mistaken. It is also possible that the service is getting confused by the lack of
##
at the end of the first two lines of your template. I feel like whatever is causing this is going to be something relatively minor-seeming/subtle/non-obvious.– Michael - sqlbot
Nov 15 '18 at 16:54
I don't think defining the path parameter in the integration request is doing what you intend, and that might be problematic, though I could be mistaken. It is also possible that the service is getting confused by the lack of
##
at the end of the first two lines of your template. I feel like whatever is causing this is going to be something relatively minor-seeming/subtle/non-obvious.– Michael - sqlbot
Nov 15 '18 at 16:54
The path parameter is getting substituted correctly, as I can see the request is sent with the expected body (clientKey is 'TEST' in this example, and you can see that in the value of the QueueUrl parameter in the request body. I wondered about the double slash in the request url, but if I take / out of the path override, the request fails. I noticed that my region in the body is us-east-2 and our queue is in us-east-1. I thought I had found the forehead-slappingly obvious reason for the error. But after I changed it to us-east-1 I still get the same issue.
– Eric Wood
Nov 15 '18 at 17:59
The path parameter is getting substituted correctly, as I can see the request is sent with the expected body (clientKey is 'TEST' in this example, and you can see that in the value of the QueueUrl parameter in the request body. I wondered about the double slash in the request url, but if I take / out of the path override, the request fails. I noticed that my region in the body is us-east-2 and our queue is in us-east-1. I thought I had found the forehead-slappingly obvious reason for the error. But after I changed it to us-east-1 I still get the same issue.
– Eric Wood
Nov 15 '18 at 17:59
I added my policy in case there is anything in there. I tried hardcoding 'TEST' as well as using '*" for resources, but neither had any effect.
– Eric Wood
Nov 15 '18 at 18:47
I added my policy in case there is anything in there. I tried hardcoding 'TEST' as well as using '*" for resources, but neither had any effect.
– Eric Wood
Nov 15 '18 at 18:47
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53308645%2funable-to-determine-service-operation-name-to-be-authorized-when-using-api-gatew%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53308645%2funable-to-determine-service-operation-name-to-be-authorized-when-using-api-gatew%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Verify that in the Integration Request, the HTTP Method is set to
POST
.– Michael - sqlbot
Nov 14 '18 at 23:53
Thanks. I posted a screenshot of my Integration Request. HTTP method is set to POST; does everything else look okay?
– Eric Wood
Nov 15 '18 at 15:39
I don't think defining the path parameter in the integration request is doing what you intend, and that might be problematic, though I could be mistaken. It is also possible that the service is getting confused by the lack of
##
at the end of the first two lines of your template. I feel like whatever is causing this is going to be something relatively minor-seeming/subtle/non-obvious.– Michael - sqlbot
Nov 15 '18 at 16:54
The path parameter is getting substituted correctly, as I can see the request is sent with the expected body (clientKey is 'TEST' in this example, and you can see that in the value of the QueueUrl parameter in the request body. I wondered about the double slash in the request url, but if I take / out of the path override, the request fails. I noticed that my region in the body is us-east-2 and our queue is in us-east-1. I thought I had found the forehead-slappingly obvious reason for the error. But after I changed it to us-east-1 I still get the same issue.
– Eric Wood
Nov 15 '18 at 17:59
I added my policy in case there is anything in there. I tried hardcoding 'TEST' as well as using '*" for resources, but neither had any effect.
– Eric Wood
Nov 15 '18 at 18:47