In cloud gateway globalcors properties, i have added allowedMethods as GET, PUT and POST.
So, it blocks all the DELETE requests which are landing on the gateway.
I want it to allow certain DELETE API's even thought DELETE is not in one of allowedMethods.
Is there any possibility of achieving this by allowing only certain DELETE API's and blocking the rest
Related
There is a requirement to build an independent app (consumer & REST client) that reads an inbound message and can then POST converted JSON message to an external customer endpoints. The inbound message would have a field to indicate the "customer" to which the message should be sent.
Further, each customer endpoint can have their own security (mostly one of 3 - Oath2, basic auth , api keys).Currently there is only customer, but in future more can be onboard.
The design challenge is how can this app flexibly support POST to different customer endpoints (each with their own security), with ability to flexibly onboard new ones? What would be efficient way to store all necessary parameters in a generic way(endpoint, oath2 provider, username, password etc) to support different security as a REST client?
-TIA
NOTE: Putting all efforts to avoid making the question opinionated.
I'm quite new to Laravel & I just made an API for my website using API Resources. It fetches all objects from the database, and is able to add new ones using POST/PUT requests.
As for my question, is it correct that everyone is able to make POST/PUT requests and add or update my database rows? If so, how do I prevent such actions from the public?
My idea is to create a microservice approch with graphql and serverless.
I'am thinking about creating a service for every table in the dynamodb and then create a apigateway service, and in the apigateway service use graphql-tool to stitch the schemas together.
This work pretty good and I'am satisfied.
But now I want to add authorization to my graphql queries and mutations.
I have added a custom autherizer in the apigateway that resolves the JWT token from the client and sends it to the graphql context with the userId
But now I want to add authorization to my resolvers.
What is the best approach for this?
I want it to be as moduler as possible and and best (i think) is to add the authorization in the apigatway service so my other service stay clean. But I don't know how?
Any ideas?
You may want to look into AppSync from AWS. It will handle a lot of this for you; authorizers, querying DyanmoDB, etc.
I've built Lambda APIs using Apollo GraphQL and exposed them through API Gateway. I then used Apollo's schema stitching to connect them together. There's one really important caveat here: It's slooow. There's already a speed penalty with API Gateway and while it's acceptable, imagine jumping through multiple gateways before returning a response to a user. You can cache the schema which helps a bit. Your tolerance will depend on your app and UX of course. Maybe it's just fine - only you (or your users) can answer that.
That note aside, the way I handled auth was to accept an Authorization header and make a check manually. I did not use any custom authorizers from API Gateway. I was not using Cognito for this so it talked to another service. This all happened before the resolvers. Why are you looking to do the authorization in resolvers? Are there only some that you wish to protect? Access control?
It may not be best to add the custom authorizers to API Gateway in this case...Because you're talking about performing this action at the resolver level in the code.
GraphQL has one POST endpoint for everything. So this is not going to help with configuring API Gateway auth per resource. That means you're now beyond API Gateway and into the invocation of your Lambda anyway. You didn't prevent the invocation so you're being billed and running code now.
So you might as well write your custom logic to authenticate. If you're using Cognito then there is an SDK to help you out. Or take a look at AppSync.
We use Google APIs Calendar v3 and Google said that they'll discontinuing support for json rpc Discontinuing support for JSON-RPC and Global HTTP Batch Endpoints.
I cant find if they plan a v4 version compliant or if the current version is compliant. Documentation don't reference about it. Java Quickstart
Any information about that?
Its not just Calendar that is effected its all Google APIs discovery APIs that are effected. The batching endpoint
POST /batch HTTP/1.1
Authorization: Bearer your_auth_token
Host: www.googleapis.com
Content-Type: multipart/mixed; boundary=batch_foobarbaz
Content-Length: total_content_length
Will be discontinued around March 25, 2019. That being said i am skeptical that the client libraries have all been updated to remove it already. I am a contributor on two of them and haven't heard anything yet about removing the the batching ability from the libraries.
Google API Client Libraries have been regenerated to no longer make
requests to the global HTTP batch endpoint. Clients using these
libraries must upgrade to the latest version. Clients not using the
Google API Client Libraries and/or making custom calls to the JSON-RPC
endpoint or HTTP batch endpoint will need to make the changes outlined
below.
The global batching endpoint is
www.googleapis.com/batch
the new one is
www.googleapis.com/batch/<api>/<version>
I think the choice of words incorrect here and it they will be regenerated if needed. The change should not effect users with one exception. That being heterogeneous batch requests a single batch request containing more then one API within the call wont work due to the fact that the end point is API specific.
Now for the bad news to my knowledge there is nothing that is going to be replacing it. You will not be able to make heterogeneous batch requests. The Google apis java client library appears to use the old endpoint BatchRequest.java so if you are using heterogeneous batching your going to have to change your code by the time they update the library to support the new API specific endpoint.
Update
After a lot of back and forth with Google over the last 24 hours I have gotten some clarification on that post.
Batching will still work with the client libries
Most of the client libraries appear to already use this endpoint so there should be no change.
You will only be able to call one API within a batch request. Example you cant call drive and calendar API in the same batch request. You will have to make two batch requests one for drive and one for calendar.
There may be some edits coming to that post to clear up the language a little to be more clear.
I have updated my answer to reflect the clarifications from Google
It is not removing batching entirely.
Per the blog they are removing heterogeneous batching - accessing the same API with requests that lead to other APIs. They are also consolidating homogeneous batching (batching to the same API and leading to a singular API) to "API specific batch endpoints".
From my understanding of the blog, if you are batching several different requests, ie. a Foo request and a Bar request into a Foo API call, you will have to adjust your code to use one batch for one and one batch for the other. If you are already doing that, it is unclear whether or not you will have to change your code, perhaps newly released libraries will have a new way to handle these requests.
Do I need to send individual entity updates to WebAPI, or can I POST an array of them and send them all at once? It seems like a dumb question, but I can't find anything that says one way or another.
Brad has a blog post that talks about implementing batching support in Web API.
Also, Web API samples project on codeplex has a sample for doing batching in web API hosted on asp.net.
It seems like WEB API 2 has support for this
From the site (Web API Request Batching):
Request batching is a useful way of minimizing the number of messages
that are passed between the client and the server. This reduces
network traffic and provides a smoother, less chatty user interface.
This feature will enable Web API users to batch multiple HTTP requests
and send them as a single HTTP request.
There are a number of samples for different scenarios on this page.
https://aspnetwebstack.codeplex.com/wikipage?title=Web+API+Request+Batching
You will have to create an action that accepts a collection of items.
If all you have is an action that accepts a single item than you need to send separate requests.
With batching always think about how you would report the failures and whether a failing of a single item should invalidate the whole batch.