The front end resolves cross-domain problems through Nginx reverse proxies

The solutions are as follows: JSONP CORS WebSocket but these ways are based on the server configuration, that is, for their own websites can be solved by these ways, but now encounter another requirement (mentioned before, write scallop plug-in, we can not change the server configuration of the scallop, also can not send a message to ask them to configure me). This article explores how the front end solves cross-domain problems through Nginx reverse proxies. Cross Domain Again: Cross domain is browser behavior, not server behavior. In fact, the request has already arrived at the server, only to be restricted by the browser on its way back. Just as Python is capable of fetching data, it is possible to retrieve data by making a request without going through a browser. The idea is to solve cross-domain problems through Nginx’s reverse proxy. Proxy A proxy is a proxy server that stands between us and the real server through which all of our requests are forwarded. Forward proxy Forward proxy means that we cannot access Google, but I have a VPS in a foreign country that can access Google. If I access it, I ask it to access Google and send the data to me. The forward proxy hides the real client. The reverse proxy Everyone had such experiences, call 10086 customer service phone, may be a region of 10086 customer service has several or dozens of, you never need to care about what is at the other end of, call what, male, or a woman, beautiful or handsome, you don’t care, you care about your problem can get a professional solution, All you have to do is dial the switchboard number 10086, and someone will always answer you, sometimes slowly, sometimes quickly. So the switchboard number 10086 here is what we call a reverse proxy. The customer doesn’t know who the real service provider is. The reverse proxy hides the real server. When we request www.baidu.com, it’s just like dialing 10086. There may be thousands of servers serving us, but you don’t know which one it is, and you don’t need to know. www.baidu.com is our reverse proxy server, which forwards requests to the real server for us. Nginx is a very good reverse proxy server for load balancing. Reverse proxy The reverse proxy hides the real server. Nginx is a good reverse proxy server, and Apache can do the same. Nginx (pronounced engine X) is a Web server that can also be used as a reverse proxy, load balancer, and HTTP cache. The software was created by Igor Sysoev and was first publicly released in 2004. The eponymous company was set up in 2011 to provide support. Nginx load balancing in Windows I mentioned using Nginx command in Windows. Nginx reverse proxy module proxy_pass Proxy_pass is followed by a URL used to reverse proxy requests to the server specified by the URL parameter. For example, proxy_pass https://api.shanbay.com in our example above would reverse proxy matching requests to https://api.shanbay.com. Reverse proxy can be done by adding proxy_pass to your server IP address in the configuration file, such as the scallop server address here.

Configuration HTML file way to open the general case, our HTML files placed in Nginx server above, namely through http://localhost/index.html, but on the front end debug, We may be through the use of file:///E:/nginx/html/index.html to open HTML. The server is not particularly convenient to open. And the reason why we want to deploy on the server, is to use the browser’s own CORS header to solve the cross-domain problem, if you do not want to put HTML in Nginx, and want to debug HTML through the local open way, you can add their own ACCESS-Control-Allow-Origin HTTP header, Nginx.conf must be configured with http://127.0.0.1/request instead of /request.

Proxy_pass http://127.0.0.1:8080; } handle DELETE and PUT cross-domain requests. Now I have a restful interface in the background with DELETE and PUT methods, and the above configuration does nothing. DELETE and PUT cross-domain requests can be resolved by adding judgment to non-simple requests. Non-simple requests are requests that have special requirements on the server, such as the request method being PUT or DELETE, or the content-Type field being of Type Application/JSON. CORS requests that are not simple requests are preceded by an HTTP query request, called a “preflight” request. After receiving the precheck Request, the server checks the Origin, access-Control-request-method, and access-Control-request-headers fields and confirms that cross-source requests are allowed, it can respond. Therefore, in order for Nginx to handle non-simple requests such as DELETE, Nginx needs to change the configuration as follows

Proxy_pass http://127.0.0.1:8080; } We must also put our HTML code in the HTML folder in Nginx, that is, use Nginx as our front-end server. URL rewriting Sometimes we just want to reverse proxy the URL under/API to the back end. You can configure URL rewriting rules in nginx.conf as follows:

In this case, we only deal with urls under/API. In the configuration file we rewrite the URL to the actual requested URL using rewrite and proxy proxy_pass to the real server IP or domain name. Cookie If the domain name part of the Cookie does not match the domain name of the current page, the page cannot be written. So if you ask www.a.com, the server proxy_pass to www.b.com domain name, and www.b.com outputs the Cookie of domian=b.com, the front-end page still stays on www.a.com. So the browser can’t write the Cookie. Can be set in nginx reverse proxy:

Summary Nginx solves cross-domain problems by using Nginx reverse proxies to divert requests from real servers to local servers to avoid browser “same-origin policy restrictions”. This article from https://blog.csdn.net/weixin_39923425/article/details/81217337