Description
CORS (Cross-Origin-Resource-Sharing) is a mechanism that allows a web application running at one origin to access the resources from a server running at a different origin. The same-origin policy is a very restrictive measure because it only allows applications on the same origin as the server to access it’s resources but it also brings the benefits of not having to trouble with security issues.
Very often we need to grant access of our resources to a third party, or perhaps it’s an internal requirement to have an application running on a different host. Fortunately CORS allows us to protect our server from abusive external calls. CORS allows us to defined (among other settings) who can access our resources.
Preflight
A prefligh request is sent to check if the CORS protocol is understood. For simple requests the preflight condition is not checked. A simple request has the following limitations
- Methods : GET/HEAD/POST
- Headers : Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Width, ViewportWidth
- ContentType : application/x-www-form-urlencoded, multipart/form-data, text/plain
For a simple request the server must only allow the origin by adding the following header: “Access-Control-Allow-Origin:*”
With a preflighted request the browser will automatically send an initial request with the method OPTIONS to determine weather the actual request is safe to send.
A ViewComponent can act like a view, you can add a layout and since the layout is what triggers the method to take whats in @section{…} and place it somewhere else, it will do so. But a ViewComponent is isolated and act independently, therefore it will take the mentioned actions in it’s own space. It will take the @section parts and it will inject then in the layout defined space using it’s own layout within it’s own container space.
See the example below (left image : layout for view component, right image : view component’s view)
Api Example - without cors headers
The bellow example show that a call from a blazor app running at a different origin will fail because the server does not issue the “Access-Control-Allow-Origin” header
The API
The Blazor App Call
This call is a simple request, but it still fails because the server doesn’t trust the origin. We can fix this by telling him to trust it.
Api Example - Allowing Simple Requests
[HttpGet] public IEnumerable Get() { Response.Headers.Add("Access-Control-Allow-Origin", "*"); var rng = new Random(); return Enumerable.Range(1, 5).Select(index => new WeatherForecast { Date = DateTime.Now.AddDays(index), TemperatureC = rng.Next(-20, 55), Summary = Summaries[rng.Next(Summaries.Length)] }) .ToArray(); }
Api Example - Sending a preflighted request
To simulate a preflighted request, we will simply add a header to our request in the blazor app. Note that this is not a predefined header, it’s a custom header that I want to pass on to the server.
Without changing the web api, you will see that this call fails and if you open the developer console in chrome you will also see why
Remember that the preflight request is using the method Options? Well all we have to do is send it a 200 status codes with the appropiate headers. And for our request we will also specify the name of the header.
The first request is the Options request:
And the second request is our request:
You can see now that 2 requests have been performed, and we no longer have errors in our browsers meaning that the request was successfully and the response received.