The front-end is 192.168.123.90, and the back-end is 192.168.123.2. This morning I found that the user login reported a login failure (essentially because cookies could not be set). At first, I thought there was something wrong with the back end, but recently I did not change the logics related to user login. Later, it is ok to switch to Firefox and Edge, and some people can log in normally with Google.
The debug message for the offending Google browser reports the following error:This set-cookie didn't specify a "SameSite" attribute and was defaulted to "SameSite=Lax" and broke the same rules specified in the SameSiteLax value
Combined with the above analysis, the preliminary judgment is that the new Version of Google browser for Cookie cross-domain restrictions.
As of Chrome 51, a SameSite attribute has been added to the browser Cookie to prevent CSRF attacks and user tracking. This setting is currently off by default. After Chrome 80, this feature is enabled by default.
1. Quick solutions
For browsers after Google 80
1.1 disable SameSite
Google Chrome accesschrome://flags/#same-site-by-default-cookies
Address, set this option for cookies to disabled, and restart the browser.
1.2 Modifying source Code
In set-cookie, change the SameSite property value to None and set the Secure property to true. However, the domain name of the back-end service must be accessed using HTTPS.
The best solution is to use token instead of Cookie to authenticate user login
2, Samesite
cookiesSameSiteProperty is used to limit third-party cookies, thereby reducing security risks.
It can set three values:
- Strict
- Lax
- None
2.1 Strict
Strict is the strictest and completely forbids third-party cookies. Cookies are never sent across sites under any circumstances. In other words, cookies are carried only if the URL of the current web page matches the target of the request.
Set-Cookie: CookieName=CookieValue; SameSite=Strict;
Copy the code
This rule is too strict and can lead to a very bad user experience. For example, if there is a GitHub link on the current webpage, users will not have GitHub cookies when they click the jump, and the jump will always be unlogged.
2.2 Lax
The Lax rule is slightly relaxed, and third-party cookies are also not sent in most cases, except for Get requests that navigate to the target url.
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Copy the code
A GET request to navigate to a target url consists of only three cases: links, preloaded requests, and GET forms. See the table below.
Request type | The sample | normal | Lax |
---|---|---|---|
link | <a href="..." ></a> |
Send a Cookie | Send a Cookie |
preload | <link rel="prerender" href="..." /> |
Send a Cookie | Send a Cookie |
GET the form | <form method="GET" action="..." > |
Send a Cookie | Send a Cookie |
POST form | <form method="POST" action="..." > |
Send a Cookie | Don’t send |
iframe | <iframe src="..." ></iframe> |
Send a Cookie | Don’t send |
AJAX | $.get("..." ) |
Send a Cookie | Don’t send |
Image | <img src="..." > |
Send a Cookie | Don’t send |
Setting Strict or Lax basically eliminates CSRF attacks. Assuming, of course, that the user’s browser supports the SameSite property.
2.3 None
Chrome plans to make Lax the default. At this point, the site can choose to explicitly turn off the SameSite property and set it to None. However, the Secure attribute must be set at the same time (cookies can only be sent through HTTPS). Otherwise, cookies are invalid.
The following Settings are invalid.
Set-Cookie: widget_session=abc123; SameSite=None
Copy the code
The following Settings are valid.
Set-Cookie: widget_session=abc123; SameSite=None; Secure
Copy the code
Refer to the link: www.ruanyifeng.com/blog/2019/0…