Asp.net Core CORS (cross-origin Resource Sharing) experiment, corecors

Asp.net Core CORS (cross-origin Resource Sharing) experiment, corecors

Environment: Asp. Net Core 2

1. Problems

Recently, when a project calls a remote UI, the font file cannot be loaded when the remote CSS file is called. Definitions of fonts in remote CSS files:

@font-face {    font-family: 'FontAwesome';    src: url('../fonts/fontawesome-webfont.eot?v=4.7.0');    …}

The browser did not access the remote Font Resource as expected and throw an exception:

Is the CORS policy blocking access from http: // localhost: 2093 http: // www. */js/font-awesome/fonts/fontawesome-webfont.woff2? The requested resource does not have the "Access-Control-Allow-Origin" header.

According to the exception information thrown by the browser, it is clearly related to the CORS policy, and the first thing that comes to mind is the Cors middleware. Modify Startup. cs to set CORS policy to allow all headers, allow all source addresses, and allow all methods.

public void Configure(IApplicationBuilder app, IHostingEnvironment env){    …    app.UseCors(builder =>        builder.AllowAnyHeader().AllowAnyOrigin().AllowAnyMethod());    …}

Unfortunately, the above policy does not affect the result, and an error is still reported when accessing the remote font. It seems that the problem is not that simple. The problem is caused by CORS policies. I also want to take this opportunity to learn more about CORS. So I designed a small experiment to deepen my understanding of CORS.

 

2. Review CORS

CORS has been introduced in many articles on the Internet. I will not go into details here. For details, refer:

Http://www.cnblogs.com/artech/p/cors-4-asp-net-web-api-02.html

Http://hbin.me/blog/2015/08/17/cross-origin-resource-sharing/

The basic CORS rules are as follows:

• The request header needs Origin: http://www.foo.com,
• The Response Header requires Access-Control-Allow-Origin: http://www.foo.com.

Let's take a look at the complete CORS workflow:

Step 2: the browser sends a request to the WebApp with the address http: // localhost: 1st;

Step 2: WebApp returns the Html page to the browser;

Step 2: the browser parses the page and determines cross-Origin resource access. The browser encapsulates cross-Origin resource access requests according to CORS rules and adds Origin: http: // localhost: 3rd to the header;

Step 2: The resource server localhost: 4th receives the request and compares the Received Header with the CORS policy. Response is returned if the policy is met. The response header contains Access-Control-Allow-Origin: http: // localhost: 1900,

Finally, the browser receives a response and determines whether the header complies with the CORS policy. if it complies with the CORS policy, the response is displayed. If it does not comply with the CORS policy, the response is blocked.

Through the above process, we can see that CORS depends on the browser, because the browser is responsible for determining whether it is a cross-origin request-based row encapsulation. After receiving the response, the browser determines whether the browser meets the CORS rule and displays it. Next, let's take a look at the role of browsers in CORS through an experiment.

 

3. experiment environment

The server uses WebApi http: // localhost: 1800/api/values to expose a service as the accessed resource. CORS policy:

app.UseCors(builder => builder.WithOrigins("http://localhost:1900"));

Prepare four different client environments:

Process

First, we access the three Web addresses with port numbers 1900, 2000, and 2100 respectively in the browser, and then use Postman to directly call the remote address.

Result

The expected results are also obtained when the condition of WebApp1 fully complies with the CORS policy.

WebApp2 is blocked because the browser initiates an xhr and does not comply with the policy.

The WebApp3 request is initiated by the HttpClient behind the request and is not passed through the browser. HttpClient initiates a request and has the information required to encapsulate CORS. It is only a simple request to http: // localhost: 1800/api/values. The server returns the result "truthfully, note that the server CORS policy does not take effect at this time. HttpClient receives the response and displays the result on the page. The whole process has no CORS shadow.

Finally, use Postman to call the remote address. The principle is exactly the same as that of HttpClient access.

 

4. Summary

CORS is effective only when the browser + XHR is used. It is a coordination mechanism between the browser and the server and cannot be used as a security mechanism.