At present, when I am in my blog, considering the use of frontend and backend separation, I separately deploy the frontend and backend logic on two version libraries and deploy them on two servers. My primary domain name is godtail.cn (currently ghost is used, and a new blog is writing ...) front-end domain name: www.godtail.cn | godt... at present, when I am in my blog, considering the use of frontend and backend separation, I separately deploy the frontend and backend logic on two version libraries and deploy them on two servers.
My primary domain name is:godtail.cn(Currently usedghost, The new blog is writing ...)
However, a message is displayed during communication.Cross-OriginOkay, I thought it would not be cross-origin when the primary domain name is the same (the same domain name and different ports will also cross-origin ).
Currently, I know two solutions:
When using JSONP, I really don't like JSONP very much. It may cause security problems or decrease in efficiency (these two points are just my guesses ).
Reasons for speculation:
Can any source be accessed? will there be js injection?
The backend and front-end must be processed by JSONP. (It is not easy to write, and JSONP must be used for all requests ).
Add a cross-origin header to the backend
If there are many front-end domain names and many domain names need to be added, maintenance is required. If other systems need to request your interface, add it to the cross-origin header? Not easy to handle...
Is there a better solution?
=================== [9-22] ========================== ====
In addition, you can set the cross-origin header and ip addresses for internal calls only. If an external call is required, it cannot be met. you are not sure whether there are any browser compatibility problems with the old version.
Reply content:
At present, when I am in my blog, considering the use of frontend and backend separation, I separately deploy the frontend and backend logic on two version libraries and deploy them on two servers.
My primary domain name is:godtail.cn(Currently usedghost, The new blog is writing ...)
However, a message is displayed during communication.Cross-OriginOkay, I thought it would not be cross-origin when the primary domain name is the same (the same domain name and different ports will also cross-origin ).
Currently, I know two solutions:
When using JSONP, I really don't like JSONP very much. It may cause security problems or decrease in efficiency (these two points are just my guesses ).
Reasons for speculation:
Can any source be accessed? will there be js injection?
The backend and front-end must be processed by JSONP. (It is not easy to write, and JSONP must be used for all requests ).
Add a cross-origin header to the backend
If there are many front-end domain names and many domain names need to be added, maintenance is required. If other systems need to request your interface, add it to the cross-origin header? Not easy to handle...
Is there a better solution?
=================== [9-22] ========================== ====
In addition, you can set the cross-origin header and ip addresses for internal calls only. If an external call is required, it cannot be met. you are not sure whether there are any browser compatibility problems with the old version.
Add backendAccess-Control-Allow-Origin
As for the excessive number of front-end domain names you have mentioned, it is easy for the backend to handle the problem with some tips.
Thought:Access-Control-Allow-OriginAdd the target domain name (Origin Request Header) Instead of writing dead domain names or*
Approximate implementation (pseudo code ):
// Domain name array string [] allowOrigins = {"http://www.godtail.cn/", "http://godtail.cn/", "http://m.godtail.cn /",}; // Determine whether the origin is your front-end domain name. if yes, add if (allowOrigins. count (x => x. contains (Request. headers ["Origin"])> 0) Response. header. add ("Access-Control-Allow-Origin", Request. headers ["Origin"]);
However, the request header can be simulated, so we recommend that you compress and confuse the interface request parameter encryption front-end scripts.
Refer to Netease Cloud Music interface encryption (go to capture the package to see)
Consider adding a cross-origin header to the backend, allowing all domain names, and then filtering the domain name in the code. if the domain name does not meet the requirements, 404 is returned directly.
Nginx Reverse proxy... you answered your questions...
Set the header 'access-Control-Allow-Origin: * 'on the server side :*';
Upstairs. You can specify the access address ~
Forward domain names on servers with no front-end code input
Can the cross-origin header be written as a regular expression?
The first method I used is jsonp and callback. if there are too many such requests, it will be troublesome to write them;
The second method is to set Access-Control-Allow-Origin on response ..*?