We want to use the AWS API Gateway as the central entry point to our application and let a custom authorizer validate the provided JWT.
Thereby we have several private claims that we would like extract and then pass on to subsequent services (i.e. optimally the lambda function should return these extracted parameters and could then be mapped within the API gateway).
My question is now:
Is that possible? So far I only found auth policies that were made up of two objects: the principalId and the policyDocument.
You can't pass back any additional data at the moment, but we have this on the backlog to do along with some other improvements to Lambda authorizers that I'm sure you will find useful. No ETA for those improvements at the moment.
Edit: additional context for the authorizer response has been released. Public docs are delayed, but see my answer here: https://stackoverflow.com/a/40644554/5679071
You can use authorizers now to do so. I guess what you mean is you have a payload to extract from the JWT. You can do so with Lambda Authorizer (or custom authorizer for API Gateway's version 1 (REST API)). You can return extra info in the authorizer's response's context. It will become the underlying lambda functions' event.requestContext.authorizer. More details in my post https://shaowang.hashnode.dev/aws-lambda-functions-with-lambda-authorizer if you want to copy things in event.requestContext.authorizer into event directly with a helper decorator. Happy to take questions.
Related
I really like the way Spring cloud function decouples the business logic from the runtime target (local or cloud) and makes it easy to integrate with serverless providers.
I plan to use SCF with AWS Lambda behind an API gateway to design the backend of a system.
However, I am not completely clear on what is the recommended way to handle REST related parameters such as Query params, headers, path etc. inside the Spring cloud functions.
As per our initial analysis, we could derive two possible approaches:
When enabling “Lambda proxy integration” in API Gateway, Query params and other information are available as Message headers inside the SCF.
We can use “Mapping templates” in API Gateway to map all the required information into a JSON body and deserialize as a POJO to take input directly into the SCF.
This way, the SCF does not need to bother about how the required data is passed to the API.
What is the recommended way to achieve this? Are we missing something that enables to do this in a better way?
I don't think you are missing anything featurewise, except perhaps that it might also be convenient to work with composite functions - e.g. marshal|transform, where marshal is a Function<Message<?>, ?> and transform is the business logic. The marshal function could be generic (and convert to some sort of canonical form), and be provided as an autoconfiguration in a shared library (for instance).
My resource /api has a method POST which proxies the body to Kinesis Firehose (and then to ES). At the same time I want it to trigger a Lambda function.
I tried adding an additional method ANY to trigger the Lambda function but API Gateway seems to preference the POST handler.
I am aware that I can trigger Lambda on POST and submit from the Lambda function to Firehose but I'd prefer having those two independent from each other.
API Gateway doesn't fork a request into multiple concurrent actions. An ANY method means "any method without a defined method." Since you also have POST defined, any POST will not see the ANY.
To do what you appear to be attempting -- execute a Lambda function and make a call to the Kinesis API, you will need to write an initial Lambda function that serves as a wrapper and performs both actions -- send a request to Kinesis and send a request to Lambda (to invoke the other Lambda function) -- asynchronously if the business logic permits it -- then marshal the results into a single coherent response that meets your needs.
This first Lambda function does not need to be in the same language as the second, so for example, if the existing Lambda function is in Java, the wrapper function could be written in Node, with no negative performance implications, since it executes independently on the other side of the Lambda API.
I'm following some Azure Function tutorials on creating a REST API, this all seems straight forward. However I'm struggling to understand how I should deal with the different verbs.
Is the recommended practice to create a separate Azure Function for each verb? And then also separate functions for each variation of routing for each verb, so a e.g. a separete function for each of:
products/{productid} (GET)
products (GET, returns list)
products/me (GET returns a list of products belonging to the user making the request)
It seems to me I'm going to end up with a lot of Azure functions here. In the WebAPI approach I would have put all these in a single controller and the attribute routing would have taken care of the rest.
Is there another way to achieve this with Azure function?
You can use Azure Function Proxies to setup routing for HTTP verbs and parameters and then pass the call down to a single function. Creating a function per each verb/parameter combination seems to be an overkill.
Of course, if processing logic is completely different e.g. for GET vs POST, it makes sense to put those into separate functions. So, in the end it's your call, but you have tools for both scenarios.
I'm designing a REST api, following best practices, including a form of hypermedia/hateoas. I'm using jsonapi for the design guidelines, which seems to be pretty complete.
Currently, I have a need for:
combining 2 resources in a response (a Resource A and a related Resource B). I do this using the Compound Documents - structure as specified in jsonapi. Or also commonly known as resource expansion
formatting the result of 1. in a specialized way so it can be readily consumed by a specialized client that expects said formatting.
My problem is with 2. How do I correctly represent this in a REST-way? It seems I may need a separate endpoint, but that wouldn't be 'RESTy', since that implies a separate resource, while it's just a transformation of the output of the same resource.
Any references on how to do this?
You could use a header or a query param to handle this.
When the client needs specific formatting, they could add an additional header to the request something like Format:Indented or something like http:\\myapp.com\resouces\myresource?format=indented
Or if the server is formatting and wants the client to know that the response is pre-formatted, the server could add a Format response header to notify the client that response is formatted.
I am designing a REST api for creating a resource using POST method.
This create call accepts 4 parameters which are mandatory but not logically related to each other.
So I have two options to accept these 4 input parameters as -
Part of request as json object
OR
In the form of query parameters as (POST /api/someresource?param1=value1¶m2=value2)
which option is most suitable?
Is there any guideline which suggests to choose one among above two methods based on the fact -
that these are mandatory parameters so we should not use query parameters?
these are not logically related but just a input to create a resource; so we can use query parameters?
/api/someresource?param1=value1¶m2=value2 is likely a GET request and not POST request.
If your request changes a state on the server then use POST. If its only a read operation use GET.