ASP. NET Core CORS (cross-domain resource sharing) experiment

Environment: ASP. NET Core 2

1. Questions

The recent project encountered a point when invoking the remote UI and could not load the font file in the remote CSS file when it was called. Definition of font for remote CSS files:

@font-Face{    font'fontawesome';    Src:url ('.. /fonts/fontawesome-webfont.eot?v=4.7.0');    ...}

The browser did not access the remote font resource as expected and threw an exception:

The effect is that cors policies prevent fonts from accessing http://www.*/js/font-awesome/fonts/fontawesome-webfont.woff2?v=4.7.0 from http://localhost:2093. The request resource does not have a "access-control-allow-origin" header.

Judging by the exception information thrown by the browser, it is obviously related to the Cors strategy, the first time to think of the cors middleware. Modify Startup.cs the Cors policy to allow all headers, allow all source addresses, and allow all methods.

 Public void Configure (Iapplicationbuilder app, Ihostingenvironment env) {    ...     =        Builder. Allowanyheader (). Allowanyorigin (). Allowanymethod ());    ...}

Unfortunately, the above strategy does not affect the results, access to remote fonts still error. It seems that the problem is not so simple. The problem is caused by the cors strategy, and I want to take this opportunity to cram the knowledge of cors, and designed a small experiment to deepen the understanding of cors.

2. Review Cors

There are many articles on the internet, Cors, which is not mentioned here, can refer to:

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 rules for Cors are:

• The request header needs to have origin:http://www.foo.com,
• The response header needs to have access-control-allow-origin:http://www.foo.com.

Take a look at the Cors complete workflow flowchart:

1th Step: The browser to the address of http://localhost:1900 WebApp request page;

2nd step: WebApp return HTML page to the browser;

The 3rd Step: Browser parsing page, determine cross-domain resource visit, browser according to cors rules for cross-domain resource access request encapsulation, add origin:http://localhost:1900 in the header;

4th Step: The resource server localhost:1800 receives the request, and the received header is compared to the cors policy. The response is returned with the response header with access-control-allow-origin:http://localhost:1900,

The last browser receives a response that determines if the header conforms to the Cors policy, matches the display, and then blocks the non-conformance.

The above process shows that Cors relies on the browser, as it is the browser's responsibility to determine whether the cross-domain request is in line encapsulation, and when the response is received, the browser determines whether the Cors rules are met and displayed. Next, let's look at the browser's role in cors with an experiment.

3. Experimental environment

The server uses WEBAPI http://localhost:1800/api/values to expose a service as a resource to be accessed. The Cors policy is:

App. Usecors (builder = builder). Withorigins ("http://localhost:1900"));

Prepare four different client environments:

1. WebApp1 on Http://localhost:1900/using AJAX calls Http://localhost:1800/api/values
2. WEBAPP2 on Http://localhost:2000/using AJAX calls Http://localhost:1800/api/values
3. A simple request call is initiated on WEBAPP3 http://localhost:2100/using httpclient http://localhost:1800/api/values
4. Install postman on any host

Process

First we access three web addresses in the browser with port numbers 1900, 2000, 2100, and finally call the remote address directly using postman.

Results

The WEBAPP1 situation is fully consistent with the Cors strategy and is expected to be the result.

WEBAPP2 a XHR is initiated by the browser and is not compliant with the policy and is therefore blocked.

The WEBAPP3 request was initiated by the httpclient behind it and did not pass through the browser. HttpClient when initiating the request and have the information required to encapsulate the cors, just a simple request to http://localhost:1800/api/values, the server "truthfully" returned the results, it should be noted that the server cors policy is not effective at this time, HttpClient received a response and presented the results on the page, and the whole process did not have a cors shadow.

Finally, the remote address is invoked using postman, which works exactly like httpclient access.

4. Summary

The cors policy is only valid for browser +XHR, which is a coordination mechanism between the browser and the server and cannot be used as a security mechanism.

ASP. NET Core CORS (cross-domain resource sharing) experiment