.passthrough() OPTIONS integration does not work for XHR requests about deprecated-hookshot HOT 3 CLOSED

Furthermore, the actual lambda function that you're passing through to needs set Access-Control-Allow-Origin to '*'.

A better implementation here would be one where:

• hookshot.passthrough creates a lambda function that is invoked by api-gateway
• that function receives all the data and handles CORS by directly answering OPTIONS requests
• if its not OPTIONS, the lambda function invokes the caller's function as RequestResponse
• wrapper lambda receives the payload, wraps it up in the right headers, and sends back the response to api-gateway

from deprecated-hookshot.

I've tinkered a little bit, trying to figure out how I might do this. I don't think I made very meaningful progress. Some questions:

• Lets call the new Lambda function PassthroughLambda. Would we want PassthroughLambda to be the IntegrationMethod for both OPTIONS and POST methods? I'm not sure how I could insert a Lambda function into IntegrationMethod. Would I be able to set the Uri to cf.sub(arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${PassthroughLambda.Arn}/invocations) ?
• How can PassthroughLambda invoke the caller's Lambda function?

from deprecated-hookshot.

The PassthroughLambda would be invoked by EVERY api-gateway method. If its an OPTIONS request, that lambda function would intelligently return CORS headers and would not even invoke the caller's lambda function. If it is any other type of request, it would forward the entire request payload to the hookshot caller's lambda function by using the aws-sdk to make a lambda.invoke() AWS API call.

This invocation would be of the RequestResponse type, which means lambda.invoke().promise() will resolve with data that the caller's lambda intends to send as the api-gateway response. The PassthroughLambda would get that data, slap on any needed CORS headers in, and respond to the original request.

from deprecated-hookshot.