InvalidQueryStringException on AWS_IAM secured API Gateway Lambda Proxy
up vote
0
down vote
favorite
I'm passing GET parameters to an AWS API Gateway resource Endpoint ( LAMBDA_PROXY) with serverless.
The GET Parameters are in array annotation, eg. ?filter[someKey]=someValue
, and the parameters are passed to the handler in the event object properly.
As soon as I try to apply an authorizer to that same endpoint (authorizer: AWS_IAM) and use Postman to send the correct Authorization info (AccesKey, SecretKey, SessionToken) with the same GET Request parameters, I'm receiving the following response:
StatusCode:
400 Bad Request
Headers:
x-amzn-ErrorType InvalidQueryStringException
Body:
{"message":null}
I couldn't find any good info on the InvalidQueryStringException from AWS.
Why are the GET request parameters properly passed to the handler without AWS_IAM authorizer but are rejected with AWS_IAM in place ?
Thank you for an insight on this.
amazon-web-services aws-lambda aws-api-gateway serverless
add a comment |
up vote
0
down vote
favorite
I'm passing GET parameters to an AWS API Gateway resource Endpoint ( LAMBDA_PROXY) with serverless.
The GET Parameters are in array annotation, eg. ?filter[someKey]=someValue
, and the parameters are passed to the handler in the event object properly.
As soon as I try to apply an authorizer to that same endpoint (authorizer: AWS_IAM) and use Postman to send the correct Authorization info (AccesKey, SecretKey, SessionToken) with the same GET Request parameters, I'm receiving the following response:
StatusCode:
400 Bad Request
Headers:
x-amzn-ErrorType InvalidQueryStringException
Body:
{"message":null}
I couldn't find any good info on the InvalidQueryStringException from AWS.
Why are the GET request parameters properly passed to the handler without AWS_IAM authorizer but are rejected with AWS_IAM in place ?
Thank you for an insight on this.
amazon-web-services aws-lambda aws-api-gateway serverless
PS: Testing the resource endpoint API Gateway via the AWS Console with that same query string yields a correct response...
– Andreas Siegert
yesterday
Could you just confirm you query string (values are less important than keys)?
– thomasmichaelwallace
yesterday
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm passing GET parameters to an AWS API Gateway resource Endpoint ( LAMBDA_PROXY) with serverless.
The GET Parameters are in array annotation, eg. ?filter[someKey]=someValue
, and the parameters are passed to the handler in the event object properly.
As soon as I try to apply an authorizer to that same endpoint (authorizer: AWS_IAM) and use Postman to send the correct Authorization info (AccesKey, SecretKey, SessionToken) with the same GET Request parameters, I'm receiving the following response:
StatusCode:
400 Bad Request
Headers:
x-amzn-ErrorType InvalidQueryStringException
Body:
{"message":null}
I couldn't find any good info on the InvalidQueryStringException from AWS.
Why are the GET request parameters properly passed to the handler without AWS_IAM authorizer but are rejected with AWS_IAM in place ?
Thank you for an insight on this.
amazon-web-services aws-lambda aws-api-gateway serverless
I'm passing GET parameters to an AWS API Gateway resource Endpoint ( LAMBDA_PROXY) with serverless.
The GET Parameters are in array annotation, eg. ?filter[someKey]=someValue
, and the parameters are passed to the handler in the event object properly.
As soon as I try to apply an authorizer to that same endpoint (authorizer: AWS_IAM) and use Postman to send the correct Authorization info (AccesKey, SecretKey, SessionToken) with the same GET Request parameters, I'm receiving the following response:
StatusCode:
400 Bad Request
Headers:
x-amzn-ErrorType InvalidQueryStringException
Body:
{"message":null}
I couldn't find any good info on the InvalidQueryStringException from AWS.
Why are the GET request parameters properly passed to the handler without AWS_IAM authorizer but are rejected with AWS_IAM in place ?
Thank you for an insight on this.
amazon-web-services aws-lambda aws-api-gateway serverless
amazon-web-services aws-lambda aws-api-gateway serverless
edited yesterday
asked yesterday
Andreas Siegert
64
64
PS: Testing the resource endpoint API Gateway via the AWS Console with that same query string yields a correct response...
– Andreas Siegert
yesterday
Could you just confirm you query string (values are less important than keys)?
– thomasmichaelwallace
yesterday
add a comment |
PS: Testing the resource endpoint API Gateway via the AWS Console with that same query string yields a correct response...
– Andreas Siegert
yesterday
Could you just confirm you query string (values are less important than keys)?
– thomasmichaelwallace
yesterday
PS: Testing the resource endpoint API Gateway via the AWS Console with that same query string yields a correct response...
– Andreas Siegert
yesterday
PS: Testing the resource endpoint API Gateway via the AWS Console with that same query string yields a correct response...
– Andreas Siegert
yesterday
Could you just confirm you query string (values are less important than keys)?
– thomasmichaelwallace
yesterday
Could you just confirm you query string (values are less important than keys)?
– thomasmichaelwallace
yesterday
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
Seems, that "percent-encoding" the square brackets is a way to get around the limitation of AWS API Gateway to not support square brackets as part of the query string, which is indeed a little odd.
So just "percent-encoding" the square bracket of the query string: ?filter[someKey]=someValue
to ?filter%5BsomeKey%5D=someValue
did actually help.
Besides, encoding the whole query string part, did not succeed (500, Internal Server Error), so you will very likely end up encoding just the square brackets.
Stackoverflow: AWS API gateway returns 400 error when square bracket (“[”, “]”) is in path
Ask
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Seems, that "percent-encoding" the square brackets is a way to get around the limitation of AWS API Gateway to not support square brackets as part of the query string, which is indeed a little odd.
So just "percent-encoding" the square bracket of the query string: ?filter[someKey]=someValue
to ?filter%5BsomeKey%5D=someValue
did actually help.
Besides, encoding the whole query string part, did not succeed (500, Internal Server Error), so you will very likely end up encoding just the square brackets.
Stackoverflow: AWS API gateway returns 400 error when square bracket (“[”, “]”) is in path
Ask
add a comment |
up vote
0
down vote
Seems, that "percent-encoding" the square brackets is a way to get around the limitation of AWS API Gateway to not support square brackets as part of the query string, which is indeed a little odd.
So just "percent-encoding" the square bracket of the query string: ?filter[someKey]=someValue
to ?filter%5BsomeKey%5D=someValue
did actually help.
Besides, encoding the whole query string part, did not succeed (500, Internal Server Error), so you will very likely end up encoding just the square brackets.
Stackoverflow: AWS API gateway returns 400 error when square bracket (“[”, “]”) is in path
Ask
add a comment |
up vote
0
down vote
up vote
0
down vote
Seems, that "percent-encoding" the square brackets is a way to get around the limitation of AWS API Gateway to not support square brackets as part of the query string, which is indeed a little odd.
So just "percent-encoding" the square bracket of the query string: ?filter[someKey]=someValue
to ?filter%5BsomeKey%5D=someValue
did actually help.
Besides, encoding the whole query string part, did not succeed (500, Internal Server Error), so you will very likely end up encoding just the square brackets.
Stackoverflow: AWS API gateway returns 400 error when square bracket (“[”, “]”) is in path
Ask
Seems, that "percent-encoding" the square brackets is a way to get around the limitation of AWS API Gateway to not support square brackets as part of the query string, which is indeed a little odd.
So just "percent-encoding" the square bracket of the query string: ?filter[someKey]=someValue
to ?filter%5BsomeKey%5D=someValue
did actually help.
Besides, encoding the whole query string part, did not succeed (500, Internal Server Error), so you will very likely end up encoding just the square brackets.
Stackoverflow: AWS API gateway returns 400 error when square bracket (“[”, “]”) is in path
Ask
answered yesterday
Andreas Siegert
64
64
add a comment |
add a comment |
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%2f53371401%2finvalidquerystringexception-on-aws-iam-secured-api-gateway-lambda-proxy%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
PS: Testing the resource endpoint API Gateway via the AWS Console with that same query string yields a correct response...
– Andreas Siegert
yesterday
Could you just confirm you query string (values are less important than keys)?
– thomasmichaelwallace
yesterday