I have an issue validating a request with a model when the user changes the content-type of the request in a serverless framework lambda-proxy integration
As per AWS docs, we can not change too much when using lambda-proxy integration
For example, the passthrough behavior that explains what happens when a validation model does not match the request type, can not be used on lambda-proxy integration.
My problem: I want to reject all requests that are not JSON so they must be forced to use the model validation. But at the same time, I do not want to change the integration type from lambda-proxy to lambda.
What can I do to solve this issue?
BR
One thing you can do is inspect the headers in the event object to confirm that it is the type you expect and if not return an error:
https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html
We can enforce the Content-Type header straight into the API Gateway like below.
References can be found here: https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html
Related
TL;DR:
Does stubby4j request proxying functionality support the setting of additional query params with the request which is being proxied?
Details:
I am using stubby4j HTTP stub server, the latest version (i.e.: v7.3.3) to proxy requests to another real live service when my request did not match any of the configured stubs.
I am interested to know if it is possible to pass in additional query params to the live service with the request which is being proxied?
In the official docs of the stubby4j request proxying behavior (https://stubby4j.com/docs/request_proxying.html) there is nothing mentioned about it and from what I see in my own testing, I do not think this is supported. But, I still wanted to ask on SO to check if I am simply doing something wrong.
You are correct, the the setting of additional query params on the request being proxied is not supported currently.
As per the aforementioned docs, the additive strategy only supports the setting of additional HTTP headers, which are specified in the headers property on the proxy-config object in your YAML.
But, it is pretty straightforward to add the addition of query params behavior. Feel free to raise a feature request at https://github.com/azagniotov/stubby4j/issues/new/choose
I have a POST method exposed though an API in AWS API Gateway. It would process a certain JSON. But there is a weird requirement: I am supposed to accept anything and return always a 200 status code (as long as the service is available and working of course).
So if I receive a call with Content-Type: image/jpeg, application/xml or what/ever, I must be able to map the request to my Lambda function.
I have achieved to map any request to a custom type using the VTL (Velocity Template Language), the issue is that I must specify every single Content/Type I want to support in the Integration Request.
I would like to define a fallback mapping template for every Content-Type that is not among those that I have already defined. It is not allowed to specify "*/*" as Content-Type.
I can not use When no template matches the request Content-Type header option as passthrough because b y default the lambda function tries to deserialize the body from a JSON format.
Any ideas?
I think you should enable the When no template matches the request Content-Type header option. As documented your Lambda will get an API Gateway event. This event has a headers field that, on a POST should contain a content-type field. If your code understands the content-type then handle it. If not, return a response that has the correct status code and whatever is appropriate. This is not on the API gateway side but rather on the Lambda side.
See this blog for some additional ideas.
I'm trying to let user upload pictures to a lambda function for processing; using the gateway API interface.
I tried to specify a model for my POST method, but so far I keep getting the error
Invalid model specified: Validation Result: warnings : [], errors : [Invalid model schema specified]
... Not so helpful.
I understand that I cannot directly send raw data to lambda and must using some kind of formatting in-between.
What I understood is that I could make the gateway interface base64 encode the data for me.
I tried to do so by using the following model schema with the content type image/jpeg
{
"body" : $util.base64Encode($input.body)
}
How to send the image ?
There is no native support in API Gateway for binary data as you have seen. We are working on this but I don't have an ETA for you. Some customers have had success base64 encoding the data like you have in your question, only it should be in a mapping template in the Integration Request not the Method Request.
If you set the content type to image/jpeg, then the encoding will apply only when the Content-Type header on the incoming request is also image/jpeg, so make sure to set that.
You can also reject incoming requests to the method that don't send the right Content Type by setting the 'Request body passthrough' (passthroughBehavior in the API) to the recommended value ("when there are no templates defined" or 'WHEN_NO_TEMPLATES' in the API)
Docs for the passthrough behavior -> https://docs.aws.amazon.com/apigateway/api-reference/resource/integration/#passthroughBehavior
Since it seems like working with binary data and API Gateway is complicated, I think you should:
Upload the image using API Gateway as an S3 proxy
Set a trigger for your lambda function on PUT for the bucket where you've uploaded the image
I have a WebApi project based on OWIN, and I wanted to extend the result of WebApi call with some additional data, for example add localization data to response.
Initial idea was to inject that logic in a pipeline and once we get a result of API call I just have wrap that json with wrapper that will contain translation and some additional properties like time of execution.
So I wrote my own middleware put it after UseWebApi() but it's not executed because WebApi doesn't call "Next" in case it handles the request
So the question is:
How can I modify/extend Json returned by WebApi middleware?
Any other ideas how to handle such a problem with an action that has to be executed for all requests?
Thanks
Regarding the middleware:
you need to place your middleware before UseWebApi, and put your logic after invoking the next middleware; in this case your code well execute after Web API is done processing the request.
You might also want to check the following blog post, it discusses the same scenario of yours:
http://www.devtrends.co.uk/blog/wrapping-asp.net-web-api-responses-for-consistency-and-to-provide-additional-information
I'm trying to use a parse.com cloud function in a mailgun route action (forward).
My action is like this (with my app id and JS key included of course):
forward("https://myAppId:javascript-key:myJSkey#api.parse.com/1/functions/hello")
In the mailgun logs, I see it call, but I get the following error:
HTTP Error 401: Unauthorized Server response: 401 HTTP Error 401: Unauthorized
My function is just a simple response.send("OK");
Obviously I'm missing something.
Greg
The issue I think is that the Cloud Code calling convention requires you use special Parse headers, not just keys: it may be different if its being called from a browser with sets the referer headers. I'm not sure you'll be able to call it this way directly from Mailgun: you may need a proxy of some sort.
EDIT: I think you'll need to use the Express Webhook implementation instead, and then you can use standard basic authentication. Cloud Code is really for cases where you have control over the HTTP client you're using.