Recently, local debugging suddenly failed to log in to the system. At first, I thought it was the backend server that issued the version. I asked my backend colleague and said there was no cookie, and then he helped me find the reason. I did not change the login section, and then found that the development environment and test environment are ok, wondering if there is a cross-domain problem, and then found that the cross-domain related properties are also set to allow cross-domain, that is, there is no local cookie, Google, oh, it is the Google Browser version problem.

Found the problem

When the front end requests server data for the first time, there is a set-cookie attribute in the response header. Next time we will send the value of set-cookie to the server as the value of the Cookie in the request header. Debugging finds that there is a yellow warning identifier behind the set-cookie attribute value of the response header when the local request is made. Search data found that Google Browser 80 or later will change the SameSite attribute in the cookie in the request from None to Lax. As a result, the COOKIE will not be sent by default in the POST request, resulting in the request failure and login failure

To solve the problem

The SameSite attribute prevents cross-site requests from sending cookies, preventing cross-site request forgery attacks (CSRF). Therefore, the server needs to add the attribute SameSite=None. If the value of this attribute is None, the Secure attribute must be set at the same time, indicating that the server must use HTTPS. Problem solved. The server adds SameSite=None, Secure, and changes the protocol to HTTPS


This article is just a review summary of my personal solution to the problem, may be the post did not understand thoroughly the place, welcome yui pointed out, solve the problem reference: Hu Yui big guy dig gold article… Some cookie-related content is written very clearly, manually like