Hey folks! I'm using a custom authorizer as per these docs, and have setup to have an identitySource with two header parameters.
It seems the order that the values are delivered changes from request to request is not consistent: ~80% of the time it is one order, and every once in a while its the other way around.
These are the parameters in my authorizer:
$request.header.requestedbyplayerid
$request.header.authorization
And here are two example stringify's (with some redaction) of the event from my authorizer lambda from two separate requests.
Request 1:
{
"version": "2.0",
"type": "REQUEST",
"routeArn": "arn:aws:execute-api:us-east-1:REDACTED:REDACTED/$default/GET/lobby",
"identitySource": [
"dbc6fbcf-709d-4a69-bac6-ba05460eba15",
"2895635c-105c-4aad-b705-93efe366cfd6"
],
"routeKey": "GET /lobby",
"rawPath": "/lobby",
"rawQueryString": "requestedByPlayerId=dbc6fbcf-709d-4a69-bac6-ba05460eba15",
"headers": {
"accept": "*/*",
"accept-encoding": "gzip, deflate, br",
"authorization": "2895635c-105c-4aad-b705-93efe366cfd6",
"content-length": "0",
"host": "REDACTED",
"requestedbyplayerid": "dbc6fbcf-709d-4a69-bac6-ba05460eba15",
"user-agent": "Thunder Client (https://www.thunderclient.io)",
"x-amzn-trace-id": "REDACTED",
"x-forwarded-for": "REDACTED",
"x-forwarded-port": "443",
"x-forwarded-proto": "https"
},
Request 2:
{
"version": "2.0",
"type": "REQUEST",
"routeArn": "arn:aws:execute-api:us-east-1:REDACTED:REDACTED/$default/GET/lobby",
"identitySource": [
"2895635c-105c-4aad-b705-93efe366cfd6",
"dbc6fbcf-709d-4a69-bac6-ba05460eba15"
],
"routeKey": "GET /lobby",
"rawPath": "/lobby",
"rawQueryString": "requestedByPlayerId=dbc6fbcf-709d-4a69-bac6-ba05460eba15",
"headers": {
"accept": "*/*",
"accept-encoding": "gzip, deflate, br",
"authorization": "2895635c-105c-4aad-b705-93efe366cfd6",
"content-length": "0",
"host": "REDACTED",
"requestedbyplayerid": "dbc6fbcf-709d-4a69-bac6-ba05460eba15",
"user-agent": "Thunder Client (https://www.thunderclient.io)",
"x-amzn-trace-id": "REDACTED",
"x-forwarded-for": "REDACTED",
"x-forwarded-port": "443",
"x-forwarded-proto": "https"
},
I hope i'm just missing something - but if you look at the authorization and requestedbyplayerid headers in both requests, you can see they are the same values. However in the identitySource array, the items are in alternate orders in the two requests.
And yes, i know i can work around this by combining the options in to a single authorization header, however... this seems rather odd. Any hints or tips from the API Gateway or Custom authorizer teams on what is going on here would be amazing!
Ok, I can definitely do that, and that makes sense, thank you!
I would expect however, that the caching might not be quite right...? If those keys are used in an arbitrary order i'd expect a cache miss from time to time when there shouldn't be one. Minor in the grand scheme of things, but i thought it odd enough to check. Thanks!
The
identitySourcefield in the authorizer event payload is added by API Gateway after the request is received. For caching, the gateway uses the defined identity sources found in the original request from the client to derive the cache key. When the cache key is constructed the named fields (i.e.headers['authorization']orheaders['requestedbyplayerid']) are extracted from the request regardless of the order.Caching authorizer responses