The problem

Vue project, local development was fine, browser upgrade, suddenly not. Even the page is not rendered to the app, the screen is blank, as follows:

Although local development can’t load the page, the NPM run build packages the published code, and the browser can access it normally, no problem.

The project login authentication page is a unified authentication page encapsulated by another department of the company. The problem cannot be solved at the code level in the short term, so take a look at what happens after the browser is updated and see if it can be solved.

Search for

In the Network of developer tools, several request interfaces for login authentication were found, and two key interfaces returned the following information:

Failed to load response data: No resource with given identifier found
Copy the code

The interface does not return authentication information. As a result, the page rendering process cannot go on, resulting in a page rendering failure and a blank screen.

There is a new alarm in the Console, as follows:

Because Cookie JSESSIONID lacks the SameSite attribute and its default value is SameSite=Lax, the policy of SameSite has been set to Lax.Copy the code
Because Cookie "" lacks the" SameSite "attribute and its default value is" SameSite=Lax ", the policy of "SameSite" has been set to "Lax".Copy the code

SameSite is an attribute added to Chrome since version 51 to protect against CSRF attacks and user tracking (related information).

SameSite has three properties:

  • Strict is the strictest and completely forbids third-party cookies. Cookies are never sent across sites under any circumstances. Cookies are carried only when the current web page URL is exactly the same as the requested target URL.

  • 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.

  • The None site has the option of explicitly turning off the SameSite property and setting 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.

According to the above information, the updated browser has security requirements, and the set-cookie in the interface packet needs to set the SameSite attribute. By default, the request without SameSite is set to SameSite=Lax.

The project authentication interface, in the case of local development, is a cross-site & cross-domain Get request. The interface does not set the SameSite attribute. In the case of the default setting of SameSite=Lax in the browser, the request does not bring cookies, authentication fails, and the interface does not return data. The interface Failed to load response data.

When publishing production, the authentication interface is a same-origin & same-site Get request, and that’s fine.

The solution

1. Chrome 51 and 91 versions later

When running local project debugging, some interfaces need to use cookies for verification, which may involve cookie loss across domains. For the front end, to achieve cross-domain cookie sharing by the browser during the debugging project, you can set the experimental properties of the browser and close the security Settings of the browser. The operations are as follows:

  • Enter it in the Chrome address barchrome://flags
  • theSameSite by default cookies,Cookies without SameSite must be secureSet toDisabled

  • Restart the browser.

2. Chrome 91 later

The SameSite by Default cookies and Cookies without SameSite must be secure Settings have disappeared since Chrome 91. The temporary solution is to install the old version of Chrome, since I developed on the Mac, I only share the method of installing the old version of Chrome on the Mac.

For Mac, Google Chrome Stable and Dev versions cannot co-exist with the new version. If you want to update your latest browser, you can download Google Chrome Canary (which can co-exist with the stable and dev versions). Select the download address for each version, and set the Settings according to 1.

3. Set SameSite= None

The server sets the header of the response to set-cookie :SameSite=None to allow cross-site requests to send cookies.

Set-cookie: key=value; SameSite=None; Secure
Copy the code
  • Note 1: The interface must behttps
  • Note 2: NeedUACheck, some browsers cannot addSameSite=none

Safari on IOS 12 and some older versions of Chrome recognize SameSite= None as SameSite=Strict, so the server must perform user-agent checks when sending set-cookie headers. The SameSite= None attribute is not issued to these browsers

4. Use Firefox

I don’t know what happened on Windows, but luckily for the Mac, it didn’t work after the 96 update.

conclusion

If the interface depends on cookies, the front-end does not send cookies. As a result, the interface does not return data. Failed to load response data: No resource with given identifier found

Browsers are increasingly concerned with front-end security and user privacy, and it is now the browser default policy that forces interface security to be upgraded.

Some generic service interfaces are best addressed by server Settings. Otherwise, in the third party development process, encountered the problems described in this article, really speechless, said that the front end of the problem is also ok, said that is not the front end of the problem, seems to be right. As browser security policies continue to be updated, so will server-side interface security policies, especially for projects that do not collect user information or do not advertise. It is not a problem that production environments strictly enforce SameSite’s security policies. For third party development, just note the Settings.

The resources

  • 1. Chrome changes SameSite Settings

  • 2. [SameSite attribute of Cookie] When Chrome version is upgraded, tripartite cookies are disabled

  • 3. Predict the SameSite attribute of cookies in a recent interview test