It’s been months since I wrote something on this blog, and I do apologise for that, however I have to admit that I’ve been very busy. I moved countries and the build up to that, the actual moving, and the aftermath kept me occupied for quite a while.
Anyways back to business. The past three or four months I have been using Microsoft Azure’s services, mainly the Function Apps and the API Management (APIM). It has been quite a learning curve as I had never worked with cloud services before, or at least not to this extent. Just like every piece of technology it has its pros and cons, and I will probably cover this in another post, however overall I would say that my experience has been quite positive so far.
On this project I was implemented Function Apps to be used as a web API. The Function Apps were connected to the APIM for better maintainability. Through the APIM I could publish different versions of the API, have several duplicates of the same API but each would hit a different environment, manage my OpenAPI specification and add inbound or outbound policies according to my needs.
One issue I came across though was allowing cross-origin requests (also known as CORS) for the API I was working on. What is CORS though? Cross-origin resource sharing (CORS) is a request for a resource (data, web page, image, file) outside the origin. In other words a server requesting resources from another server. In most cases GET requests are allowed however requests of type POST, PUT or DELETE would be denied to minimise potential malicious behaviour. That is exactly what was happening in my case, trying to consume the API I was hosting on the APIM (Microsoft Azure) from client-side (POST AJAX request).
One way to handle this was to add the CORS policy in the Inbound processing section within APIM. More specifically you can add the CORS policy to a specific operation as I did in the screenshot below.
After clicking the Add policy button select Allow cross-origin resource sharing (CORS) and you should get to the screen seen below.
In my case I selected the GET, POST and also OPTIONS because cross-domain AJAX request perform a so called CORS Preflight Check. This is done by modern web browser to determine whether the browser has permission to perform that action. This preflight check is an HTTP call of type OPTIONS. In my case I did not restrict anything in the origin and headers field and left the asterisk value which represents a wildcard. Furthermore you can edit the Inbound processing manually using the APIM’s editor. Here’s how it should look like after applying the changes listed above.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<policies> | |
<inbound> | |
<base /> | |
<cors> | |
<allowed-origins> | |
<origin>*</origin> | |
</allowed-origins> | |
<allowed-methods> | |
<method>GET</method> | |
<method>POST</method> | |
<method>OPTIONS</method> | |
</allowed-methods> | |
<allowed-headers> | |
<header>*</header> | |
</allowed-headers> | |
<expose-headers> | |
<header>*</header> | |
</expose-headers> | |
</cors> | |
</inbound> | |
<backend> | |
<base /> | |
</backend> | |
<outbound> | |
<base /> | |
</outbound> | |
<on-error> | |
<base /> | |
</on-error> | |
</policies> |
There are other ways to allow CORS for APIs hosted on Microsoft Azure. I found this method to be the easiest and most straight-forward for APIs that make use of APIM. That’s all for this post and I hope I would not take as long to post my next one.
Bjorn