Discitur Project

3 minute read

What does Cross-Origin Resource Sharing mean? It’s a mechanism that allows a web application to access resources in another domain.

Why is it for? for a number of reasons, all very valid and current:

because with the intensive use of javascript libraries that make AJAX call and the explosion of social networks that provide access to its resources, web applications have become real “rich client application”, which are able to call an high number of functionality and data from external sources
for safety issues. In fact, all browsers implement a policy that prevents web applications to access external resources except under certain characteristics (same-origin policy).

Why do I talk about? Because it helped me to create an environment of User Acceptance Test completely free! (Venal, but it’s true). Seriously, I set the goal to get low-cost and after a while has become almost a personal challenge. In fact in the .NET world are not many providers that allow you to have a server without activation fees or dues (on this front, colleagues of PHP have an easier life).

What I found is Somee.com: for small or test provides Windows Server 2012 (to date) with SQL Server without incurring any cost. The management interface is a bit spartan, but with the usual access FTP you can do what it takes.

Beautiful! Except that Somee.com imposes to display into the HTML pages returned by their free servers a bit of advertising. I am not against this barter. The problem lies in how fit this advertising…in fact they made sure that every resource html request to the server is returned with the following suffix:

This “trick” has the unfortunate effect of completely break my angular.js application!!!

In fact all the directives require that the own template has a unique root-node…which, with Somee.com, is no longer true…

I have not resigned myself to the thing (because, from newbie, deploying for the first time the application on these servers, cost me several hours) and I thought back to what mentioned in a previous article, namely that, thanks to the organization of services and use of a unique baseUrl, is very simple to indicate which server Angular uses for RESTful calls. GOOD!

Thanks to Github (which I will never cease to thank!) anyone who registers has available (free of charge), a web space for the publication of their material: Github Pages, that is, precisely, the space where I publish these articles. At this point I think I have everything and I could realize my environment with this UAT Environment Management:

Each client then polls the Github server for static resources (.html, .js, .css, etc.) And the Somee server for dynamic resources (services). In this scenario, the client must be able to do CORS call and the web API must be configured to allow access from the outside. Given this scenario, I would also expect that the authorized origin could be configurable and undoable (because production would have different origins or I may have no need of this scenario).

To do this, I followed these simple steps:

installation of Microsoft.Owin.Cors library
Creating a configuration section for CORS
Creating a a href=”https://github.com/williamverdolini/discitur-api/blob/sprint5/App_Start/Startup.Auth.cs#L107” target=”_blank”>custom class CORS Policy</a> (with the source to be enabled)
Setting CORS policy according to the data in configuration

It works. And it’s free!

##Preflighted requests##

It was interesting to see the work the preflighted requests, which are one of the CORS’s policy behaviours browsers apply. Consists in the fact that the browser, under particular conditions (eg. For the presence of custom header), always to ensure safety, before performing an Cross-Origin http request, “knock” to the server with a light request, with basic header and OPTIONS method, to make sure that this call is recognizable by the server.

In the Discitur UAT environment, this behavior is very obvious, in fact, as a result of authentication, through the use of Angular.js interceptor, I insert a custom header with the authentication token. This additional token puts the browser on alert, which starts the mechanism of preflighted requests.

If there is traffic on the application, you can see that before authentication you have simple requests: