Using tegola lambda with AWS API gateway

[ARolek]

@ARolek One last question for you (I promise!). I'm trying to add AWS Cognito authentication to the API Gateway that calls the Tegola Lambda function.

For some reason, it seems to be failing with CORS whenever I add any headers to fetch the API endpoint. I've spent half a day looking up StackOverflow threads and have tried adding Access-Control-Allow-Origin = "*" Access-Control-Allow-Methods = "GET,OPTIONS" Access-Control-Allow-Headers = "Origin,Content-Type,X-Auth-Token,Authorization" Cache-Control = "no-cache, no-store, must-revalidate" to:

• Config.toml
• Gateway Responses (4xx and 5xx) under API Gateway
• API Gateway "Enable CORS"

Every time (after deploying), I still get 500 (Internal Server Error) Access to fetch at 'URL' from origin '' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.

Note that the second I turn off "Authorization" under the "ANY" Method in the API Gateway and remove the "Authorization" header, the call works. Any thoughts? The problem seems to be in sending the headers rather than the actual authorization as it fails any time I send any header (regardless of authorization requirements).

[ARolek]

@stdmn I would like to not hijack the other issue so I have moved your question here.

This sounds like it's going to need a bit more debugging.

• Are you getting this in the client side console or the server logs?
• If this is client side, have you confirmed everything is working end to end if you run the client side code on the same domain as tegola? This will confirm it's a CORS issue so debugging can be focused there.
• If it is a CORS issue, can you post what the response headers look like to a tile request for both the OPTIONS and the GET requests? If the required CORS headers are missing we can start working on why they're not properly set.

[stdmn]

@ARolek OK, I think I may have figured out the problem, just don't know how to fix it.

It looks like the culprit was making "Binary Media Types" = */*. I think this is messing with the OPTIONS call. When I remove this, everything works fine. The problem is that if I remove this, Tegola doesn't work.

I suppose I could just add a separate request CORS header with a type that API Gateway reads as binary. What are your thoughts on the best way to go about this?

[stdmn]

I was able to solve it. Here's what I did:

1. When setting up the API Gateway, instead of using '*/*' under 'Binary Media Types', use 'application/octet-stream'

2. Under the {proxy+} method, include an Authorizer (I used Cognito ID per [AWS docs]).(https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html)

3. For every call to API, include "Authorization" header with token

   1. This includes tile calls, which will require a Transform Request when you instantiate the map
   2. For reference, here's what my transform request looked like: transformRequest: (url, resourceType) => { if (resourceType === "Tile" && url.includes(rootURL)) { return { method: "GET", url: url, headers: { Authorization: `${resolve.idToken.jwtToken}` } }; } }

4. Enable CORS for the {proxy+} method. Make sure that 'Access-Control-Allow-Headers' includes 'Authorization'. For reference, here's what my settings looked like:

That should do it. Thanks for the help @ARolek !

[ARolek]

@stdmn awesome! Thanks for the follow up on the solution. Just so this thread is complete, you have essentially implement token authorization in front of the API endpoint using API Gateway.

Are you using this for metering tile requests or restricting access to tilesets?

[stdmn]

Exactly. I'm using this for restricting access to the tilesets. Specifically, I didn't want someone to be able to go in and download the tiles by using a direct link in the browser.

[ARolek]

Great! Let me know if you're able to share your project when it's ready. I'm considering putting a list together of where tegola is being used.

Let me know if you have any other questions.