allow CORS on azure api management

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.

CORS1

After clicking the Add policy button select Allow cross-origin resource sharing (CORS) and you should get to the screen seen below.

CORS2

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.


<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

adding an existing file as a link in visual studio

Testing is an essential phase in the software development life cycle. I almost dare to say that no software or application(web or desktop) was ever released without testing it first. As most .NET software developers I rely on test projects to create my unit tests and test my implementations. I find it practical, efficient, it helps me identify bugs, run dummy tests, evaluate the outcomes; in other words it’s good and you should make use of it if you don’t.

One feature I don’t like in test projects is that certain configurations need to be replicated rather then referenced. Let’s assume that in my solution I have project A(which is my working project) and project B(which is my test project used to test project A). If I had to add my own settings in the configuration file (app.config vs web.config) of project A and then try to run a test from project B, the solution would throw an exception saying that the newly added settings was not found. Therefore to run my test I would need to copy the setting and add it in the configuration file of project B, something I’m not very fond of. A similar exception was thrown when I added a file(an XML file in my case) to project A and then ran a test from project B. Since the implementation depended on the XML file and the file was added in project A, the test failed. I then had to add the same file in project B in order to get the code running. Again, I’m not very fond of this practice and from not very fond it started to become quite frustrating.

I resorted to Google to find a solution. After some quick research I found out that an existing file can be added as a link to another project in the same solution. This is great, just what I wanted because any changes done to the file would be done once. To add an existing file as a link you must;

  1. Right click on the target project, click on Add and from the new menu click on Add Existing Item.
  2. A new directory window should pop on screen. Locate the existing file to add.
  3. Right next to the Add button, click on the arrow and from the drop down menu select, and click, Add As Link.

A new file should now show in the targeted project. Great! I did that happily convinced that all is going to be well in my test but, once again, when I ran my test project the same exception was thrown. It took me a while to realise but when I checked the bin folder of the test project the XML file was not there. Thus, the file was not being included in the build and it all makes sense why the test was still failing.

Again, I resorted to Google to find a solution to add the linked file to the build of the test project. I found a few solutions but none were working for me until I stumbled across Matt Perdeck’s blog post. In order to add the linked file to the project’s build you must find the project’s .csproj file(if it’s a C# project) and open it with an editing software, such as Notepad or Notepad++. At the very bottom, just before the closing node add the following text.


<Target Name="CopyLinkedContentFiles" BeforeTargets="Build">
<Copy SourceFiles="%(Content.Identity)" DestinationFiles="bin\Debug\%(Content.Link)" SkipUnchangedFiles='true' OverwriteReadOnlyFiles='true' Condition="'%(Content.Link)' != ''" />
</Target>

Quick build, located the linked file in the bin folder, ran the test and that’s it job done. From now on I had one file which is referenced in another project and whenever I ran the test it will always work. Hope this helps you guys too and hopefully it takes you less time to solve than it did to me.

See you’s
Bjorn