CORS helpers
jyecusch opened this issue · 2 comments
While CORS can currently be handled using middleware and by registering OPTIONS routes, we'd like to build this support into the framework to make it more convinient and ideally handle the responses as high up the infra stack as possible. For example, providing support for static responses to OPTIONS requests at the API Gateway or Nitric Server layers to reduce latency and hosting costs.
This support will be needed in all language SDKs.
Research of cloud provider API gateway pulumi configs:
AWS:
Seems pretty easy, just put them in apigatewayv2.NewApi
- allowCredentials
- allowHeaders
- allowMethods
- allowOrigins
- exposeHeaders
- maxAge
Azure:
Need to create a cors policy use apimanagement.NewApiOperationPolicy
- allowCredentials
- allowHeaders
- allowMethods
- allowOrigins
- exposeHeaders
- maxAge
GCP:
The worst of the bunch it seems, they suggest using ESP or doing it per function.
References:
https://stackoverflow.com/questions/64281334/cors-errors-when-trying-to-fetch-from-new-google-cloud-api-gateway/65738206#65738206
https://www.googlecloudcommunity.com/gc/Serverless/CORS-issue-with-API-gateway/m-p/619097
TLDR
AWS and Azure seem fine, however considering GCPs lack of support (and lack of a roadmap) Like we have suggested, we could use a load balancer or just handle it on our side, but then if we do this should we just do it consistently across any new provider or pick best prac per cloud?
Another item for discussion. Should we also include bucket CORS configuration as a new ticket?
Started work on proto contracts / integration with AWS.
Is the Bucket CORS suggestion for people who want to access the bucket from a resource other than our API?
Is the Bucket CORS suggestion for people who want to access the bucket from a resource other than our API?
Yes, but should be a new ticket if we decide to do it
This has been completed and is ready for review (in this order):