Cross-domain cookies are involved. Two systems that need to log in are embedded in each other's web pages

background:

At present, the company has two back-end systems, back-end a and back-end b. The login session is established through cookies. Now we need to make it look like a system without major transformation

Solutions:

Embed the web page of background b into background a, and background b prepares an interface 1 (the input parameter is the user name, and the output is the menu owned by the role to which the user name belongs). Before you click the menu, request interface 2 (the input parameter is the user name, the function is to plant a cookie for the user, so that you are logged in, the response will carry set-cookie, and the browser will set the cookie after receiving Go to the domain name to which interface 2 belongs, so that it can be opened directly when you click the menu of background b), the request method of interface 2 should be wrapped by the script tag, such as <script src = "URL of interface 2"> </ script > This method is not the XHR request method, so it avoids cross-domain security issues

 

Extension:

Cross-domain: as long as any of the protocol, path and port are different, it is cross-domain

There are three elements of cross-domain security issues:

1. Browser check does not allow cross-domain requests

2. The request itself is a cross-domain request

3. The request method is XHR

Only with the above three elements will cross-domain security problems occur, so when cross-domain security problems occur, the three will only need to solve one problem

Solve "Browser check does not allow cross-domain requests":

This method starts from the client's browser, so it is not practical

Solve the "Request method is XHR":

Similar to the jsonp method, this method is to change the request method originally belonging to XHR to other request methods

Solve the "self request is a cross-domain request":

This solution has two directions: 1. The callee resolves cross-domain 2. The caller resolves cross-domain

The callee resolves cross-domain: enable the callee to allow cross-domain (added in the header in the code layer or added in the nginx server configuration file)

The caller solve cross-domain: Limit the caller to use a proxy, because "cross-domain" is only between the browser and the server . We can't force remote servers to allow "cross-domain" requests, so all we can do is not use browsers to send requests. So in front-end development, a common way to circumvent cross-domain is to send the ajax request to your local development server, and then the local development server forwards the ajax request to the remote end, looking at the local development server from the network topology It acts as a "reverse proxy". The local server and the remote server are "communication between the server and the server", so there is no cross-domain problem

 

 

 

Published 25 original articles · Like2 · Visits 20,000+

Guess you like

Origin blog.csdn.net/longjuanfengzc/article/details/89712457