We're leveraging the hapi-swagger plugin to generate swagger documentation for endpoints we are proxying in Azure's API gateway service. We're exporting the swagger doc, and importing it into the Azure service.
All of our endpoints are set to cors: true, and because we are making cross origin requests, common browsers (e.g. Chrome) make a preflight OPTIONS request. Apparently Hapi automatically generates the OPTIONS endpoints for us (as in, we see the OPTIONS requests being made successfully in the browser), but it also seems that our exported swagger doc does not include these OPTIONS endpoints, and so none of the endpoints get proxied in the gateway service.
Is anyone aware of a way to export/expose these OPTIONS endpoints?
Additional information:
hapi: 16.6.2
hapi-swagger: 8.0.0
We "solved" this by turning on CORS support for each of our proxied endpoints in the Azure gateway which I guess automatically exposes OPTIONS endpoints (I wasn't doing the Azure work, so forgive my untechnical explanation; this article seems to corroborate my understanding, though it's about Azure storage services, not their api service..).
Related
CORS says that:
A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin.
That been said, look at this scenario. I have two apps deployed on the azure.
https://myApp.azurewebsites.net .NET FW app that has a Angular client.
https://myMicroservice.azurewebsites.net .NET CORE API.
Since both apps are in the same site (origin) azurewebsites does that mean that I don't need to configure CORS?
Note: I already have configured CORS on the .NET CORE app to allow the https://myApp.azurewebsites.net origin.
Here, the same origin means that xxx.azurewebsites.net should be the same one(as well as xxx).
So in your case, you need to enable CORS. Otherwise, the access is not allowed.
I'm not entirely new to MS Azure, but I am new to its API Management Service. I am trying to get an understanding of how the routing works between the client, the APIMS, and the backend APIs, but somehow can't seem to find what I'm looking for within Microsoft's documentation.
So here's what we have and what I understand:
We have multiple APIs that we host on Azure as App Services. And those APIs are added to the APIMS, which we are using as a gateway. The APIMS's Inbound policies on each API specifies the backend service as that App. But that's all I know.
So when a client, say an application running on someone's computer, sends a request to one of those APIs, how does its request URL end up routing through the gateway? And how does that all relate?
the request URL is made up as follows:
[name of your APIM service].azure-api.net/[name of api]/[api method]/[querystring]
example:
https://myapimanager.azure-api.net/myapi/getstudent?id=1
https://myapimanager.azure-api.net/myotherapi/getsomethingelse?name=bubbles
Having an issue with Azure storage CDN. We have it configured for CORS, basically we allow all headers and origins (*), and GET|HEAD|
OPTIONS. Everything works fine when we are using the storage direct host. When we switch it over to use the CDN host,the OPTIONS request stops returning any of the allow headers and causes cross origin failures. On other gets I do get the allow origin header but nothing else. Anyone seen this or am I overlooking a config option somewhere? Happens locally talking to Azure and on our Azure hosted site.
Azure CDN profiles from Akamai currently do not tunnel OPTIONS requests. There is a patch currently underway to enable OPTIONS requests for cors pre-flight.
If you don't use pre-flight requests, does CORS work?
I have some doubts about which is the most appropiate way to allow access to my company backend services from public Clouds like AWS or Azure, and viceversa. In our case, we need an AWS app to invoke some HTTP Rest Services exposed in our backend.
I came out with at least two options:
The first one is to setup an AWS Virtual Private Cloud between the app and our backend and route all traffic through it.
The second option is to expose the HTTP service through a reverse proxy and setup IP filtering in the proxy to allow only income connections from AWS. We don´t want the HTTP Service to be public accesible from the Internet and I think this is satisfied whether we choose one option or another. Also we will likely need to integrate more services (TCP/UDP) between AWS and our backend, like FTP transfers, monitoring, etc.
My main goal is to setup a standard way to accomplish this integration, so we don't need to use different configurations depending on the kind of service or application.
I think this is a very common need in hybrid cloud scenarios so I would just like to embrace the best practices.
I would very much appreciate it any kind of advice from you.
Your option #2 seems good. Since you have a AWS VPC, you can get an IP to whitelist by your reverse proxy.
There is another approach. That is, expose your backends as APIs which are secured with Oauth tokens. You need some sort of an API Management solution for this. Then your Node.js app can invoke those APIs with the token.
WSO2 API Cloud allows your to create these APIs in the cloud and run the api gateway in your datacenter. Then the Node.js api calls will hit the on-prem gateway and it will validate the token and let the request go to the backend. You will not need to expose the backend service to the internet. See this blog post.
https://wso2.com/blogs/cloud/going-hybrid-on-premises-api-gateways/
anyone have any idea how to enable CORS in the context of C# Backend Mobile Service being invoked by a JS function via the MS Azure Mobile Services JS library?? I get 405 and have looked at this link (https://gist.github.com/HenrikFrystykNielsen/6c934be6c6c8fa9e4bc8) which makes sense but no longer applies.
Mobile Services written in JS can be configured for CORS via the portal, but not C# backends.
thanks in advance
The answer in the gist still applies -- remember to load the CORS NuGet package as well.
Henrik