One, the same station strategy problem

Chrome has had so-called same-site policy issues since version 80.

That is, when Page A requests page B, Chrome does not send A cookie to the server where page B is located if it discovers that they are not the same site. As we all know, cookies were originally attached to every request from the browser to the server, as if this were a natural thing to do, but now Chrome is a case in point and doesn’t necessarily allow this.

What are the consequences of this? It’s something that used to work, but now doesn’t. Take our project for example, some of our WEB projects used iframe to embed some pages of other projects, just like the same system. This is called interface integration, and it is a normal behavior. Both sides of the project automatic login and so on, has been working fine. Then I upgraded my browser and found that the embedded page data didn’t come out. The program did not make any changes, and finally it was found that the account login problem, the embedded page was always in the login state, so that the data could not be obtained.

Specifically, a cookie is assigned to the browser by the server, giving the browser an access credential. The browser carries these credentials every time it visits the server. Now, due to the change of browser policy, when the embedded page interacts with the server, it cannot bring the cookie. The server cannot retrieve this certificate, so it allocates a new cookie to the page every time.

In fact, Chrome has always had this same-site policy. Starting with Chrome 51, the browser’s cookies will now have a SameSite property to protect against CSRF attacks and user tracking. SameSite can set three values:

Strict

Lax

None

Strict is the strictest and completely forbids third-party cookies. Cookies are never sent across sites under any circumstances.

The Lax rule is slightly relaxed and handled on a case-by-case basis, as follows



None does not check and restrict whether it is the same station. Chrome used to default to SameSite=None, but Lax has changed since version 80. This is also why chrome updates and applications suddenly fail.

Second, solutions

1. Change browser Settings. This is a simple and crude way to set the SameSite property back to None. Whether the user wants to or not, the fact that the browser on each machine has to be set up violates the principle that the biggest advantage of BS architecture applications is that the client does not need to be installed and deployed. So I think this is a measure that has to be taken when there is really no other way.

The setting method is as follows:

1) Enter Chrome ://flags in the Chrome address bar. 2) Disable “SameSite by Default cookies” and “cookies without SameSite must be secure”

Set-cookie: SameSite=None Set set-cookie: SameSite=None

Set-Cookie: SameSite=None; Secure
Copy the code

Set-Cookie

Here’s a question: Who sets the set-cookie? Take our project as an example. The page of project A uses iframe to embed the page of project B. Should project A set set-cookie or project B? It’s going to be B. Because it is embedded in the page of B project, the response comes from B server, and A can’t make it work hard.

Notice The Secure attribute must be set at the same time (cookies can only be sent over HTTPS). Otherwise, the Secure attribute is invalid. This means that project B must use HTTPS? But I tried it a few times, and it didn’t work. Maybe my project A itself is HTTP and I need both A and B to be HTTPS? Don’t know.

However, there is an instance where SameSite is set to None. Take the Adobe site as an example:www.adobe.com/sea/, view requests can be…



3. Nginx does site mapping

The SameSite policy targets requests from different stations, so there is no problem with the SameSite. Then project A embedded in the page of project B, map site B to the same site is not good? The same site and homology (non cross domain) is not the same, I feel that the same site than the same to be strict, cross domain, the same top-level domain name can be, with the same site, the domain name to keep the same, port can be different. For mapping, you can use the same domain name or IP address but different ports.

The difference between homology and homology is complicated, and you can see it here.

The best choice for mapping sites is of course Nginx. For example, A project in my local, http://localhost:8081, now embedded in the page of the project, B B project address for http://192.168.0.248:8082/, now need to be mapped to http://localhost:8082.

1) Create an Nginx configuration file /conf/nginx2.conf

worker_processes  1;

error_log  logs/error.log debug;

events {
    worker_connections  1024;
}

http {
    server {
		listen       8082;  
        server_name  localhost;  
		location / {
			proxy_passhttp://192.168.0.248:8082/; }}}Copy the code

2) Run nginx

Nginx. Exe - c D: \ soft \ nginx - RTMP - win32-1.2.1 \ conf \ nginx2 confCopy the code

Third, summary

Google Chrome’s same-site strategy is arrogant, although it does allow server B to set SameSite=None, but with HTTPS binding. Network has Internet and LAN of cent, safety is relative all the time, want to weigh together with pay price. In LAN, A and B projects are developed by themselves. Why not embed them? With HTTPS, making a certificate itself is pretty tedious. Thankfully, other browsers haven’t followed suit yet.

The SameSite properties of cookies and SameSite properties of the browser series