background
(If you want to get the solution directly, just turn to the solution section.)
I believe that there are many front-end development students like me in the past period of time (January 21, 2020 to July, when chrome91 was released). A sleep up, yesterday can normal debugging of the page, today has been repeatedly reported did not log in, and their last night when the work is still good, how to sleep on the line?
I believe that smart partners will soon be able to locate the problem, immediately offered Safair, can be used normally. So there is no doubt that chrome update (believe chrome as a front-end development must, turn on automatic update is the choice of many students). And can’t log in, is nothing more than cookies don’t carry bai, old problem.
By the way:
Not all of our current team’s current projects have this cookie problem. If you look at the code carefully, the interface request of some projects is always sent to the local domain name, while the request test environment is configured with proxy in webpackDevServer to realize interface forwarding. Since the browser always sends the interface request to localhost, the interface domain name is localhost. The local domain name is also localhost, so there is no problem that the cookie is not carried, causing login failure.
However, some H5 projects are directly sent to the domain name of the test environment. As the domain name of the localhost and interface environment are from different sources, cookies cannot be carried and login cannot occur.
History of the same-origin policy and corresponding solutions
When a request is initiated within the page, the cookie under the domain name will be carried by default. The cookie same-origin policy means that the cookie will be carried by default unless the current domain name and the requested domain name are the same, which leads to the excuse that localhost directly requests the test environment, such as APi.baidu.com. In this case, cookies are not carried. As a result, interface 301 fails to log in.
This strategy has been around since Chrome 80, with Chrome 91 upgraded and Chrome 94(due for release in September 2021) expected to be upgraded.
Before Chrome 91, you can set SameSiteByDefaultCookie to disable by opening Chrome ://flags/ in your Chrome browser.
After Chrome 91, this configuration was removed and you need to manually configure startup parameters to disable this limitation by adding the startup parameter –args –disable-features=SameSiteByDefaultCookies. Cookie can be implemented across domains. See the article for adding startup parameters automatically.
Chrome 94 is expected to remove support for startup parameters, so what will happen then?
The solution
After Chrome 94, when Chrome disables the command line operation of cross-domain cookies, I have practiced the following solutions:
Use webpack-dev-server to implement interface forwarding
Initiated in interface request, the request of the link is always localhost: yourport/your/API/name, in webpack or easy to configure the proxy of domain name can be forwarded to the API interface needs.
Of course, there are some downsides to this:
- Webpack configuration needs to be changed every time the proxy is switched, and a restart is required (some scaffolds will restart automatically, but will also automatically open a new page instead of hot updating, which is not so silky, and some scaffolds will also be hot updating).
- When the proxy configures forwarding, it usually matches the path according to the re. In some scenarios, some interfaces need to use the test domain name, and some interfaces need to use the mock domain name, which requires some separate processing. In the combination of code, development process is often more inconvenient.
Domain name Forwarding with Charles (recommended)
The reason why cookies are not carried is that the domain name of the local localhost is different from that of the test environment. As a result, cookies are not carried across domains. In this case, you only need to use the proxy tool to proxy the domain name that is in the same domain with the test environment to the local to solve the problem.
As I am familiar with Charles, I take Charles as an example.
Step1: install Charles, and then install the certificate (HTTPS information cannot be viewed without installing the certificate), Google or baidu can be used, not to be described here.
Step2: click tools > Map Remote > add, configure the following parameters (assume port 3000), save the Settings, and select enable Map Remote.
After the above configuration, requests from xxx.163.com are forwarded to port 127.0.0.1:3000. The browser can directly open xxx.163.com to return to the local page of port 3000. In this example, 163.com is only the domain name of the author. During actual configuration, ensure that the secondary domain name of the interface to be accessed is the same. Because the cookie’s cross-domain judgment only goes to the secondary domain name. Also note that HTTP and HTTPS, which are also judged to be cross-domain, do not carry cookies.
ps:
Will hot updates be lost?
Under normal circumstances, hot updates are triggered by websocket link creation. The general hot update scheme will degrade to HTTP long link when WS link cannot be established. If your hot update is not converted to HTTP long link, then you can use map remote to change ws://x xx.163.com/ *, Also proxy with ws://127.0.0.1:3000/ can be. If the long HTTP link fails, you need to observe the console hot update failed interface error, view the interface domain name rules, and proxy it to the local to solve the problem.
WEBIDE or CLOUDIDE
Generally speaking, the WEBIDE built by the company itself is basically in the same domain as the interface it wants to access. Therefore, during the development, since it is in the same domain itself, there is no problem that the cookie cannot be carried after cross-domain, resulting in the login failure.
Of course, the construction of WebIDE also requires some accumulation. Interested partners to join our team (cloud music live team), build webIDE together.
Other options
All the above schemes are feasible, and all of them have been verified by practical operation. Then there are several other schemes (but not verified by the author) :
- Forwarding tools such as Ngnix, Whistle, Fiddler and MitmProxy can select forwarding domain names and forwarding interfaces, both of which are feasible in principle
- Charles forwarding interface, the above is the forwarding domain name, so that cookie is in the same domain, theoretically there is no problem with the forwarding interface, but our interface environment is changeable, it is more troublesome to configure, not as real as the domain name
- Chrome allows cross-domain cookie carrying, but cookies must meet two conditions: the samesite property of cookies is set to None, the secure property is set to true, and the website protocol is HTTPS. Therefore, in theory, the local should be changed to https://localhost, and the server side should cooperate to complete cross-domain cookie carrying (PERSONALLY, I think the server side will not make this modification, cross-domain cookie carrying, so that THE CSRF attack is easier).
The last
Wish you all a happy upgrade! The author himself belongs to the netease Cloud music live broadcast team. The atmosphere is good and the technology keeps up with the trend.
\