The Chrome 80 update was announced by Google in February of this year — 2020. But I did not hear of it, and that is bad on my side as a software developer and maintainer of a business app. These things are so crucial that I should have been on top of it.
Google在今年2020年2月宣布了Chrome 80更新。但是我没有听说过，作为软件开发人员和业务应用程序的维护者，这对我来说是不好的。 这些事情至关重要，以至于我应该紧紧抓住它。
Anyways, the update is a good one. It is focused on security for chrome-based browsers like Google Chrome, Opera, Internet Explorer, etc. It was announced in February and rolled out using the Canary model of deployment.
无论如何，更新是一个很好的更新。 它专注于基于Chrome的浏览器(例如Google Chrome，Opera，Internet Explorer等)的安全性。它于2月份发布，并使用Canary部署模型推出。
This means that some select users — determined by Google — would have received the update first, and then gradually more and more people would receive it depending on whether it panned out well for the first receivers.
这意味着，由Google确定的某些精选用户将首先收到更新，然后逐渐有越来越多的人收到此更新，具体取决于该更新是否适合第一批接收者。
Many chrome-based browsers have not yet upgraded to the new Chrome version as of yet, but it is imminent they will eventually. As long as there are not more than enough complaints about it, they will.
到目前为止，许多基于Chrome的浏览器尚未升级到新的Chrome版本，但最终将迫在眉睫。 只要投诉不多，他们就会。
That said, apart from the possible bug fixes and other stuff in the update, there is one highlight new feature that can possibly break many websites.
也就是说，除了可能的错误修复和更新中的其他内容外，还有一项突出的新功能可能会破坏许多网站。
I recently visited a client’s website just for maintenance protocols and found out that I could not sign in. So I did what every web developer would do: I checked the browser console.
我最近访问了一个客户网站，只是为了了解维护协议，结果发现我无法登录。因此，我做了每个Web开发人员都会做的事情：我检查了浏览器控制台。
Lo and behold the error, was staring at me
罗，看错了，盯着我
背景 (Background)
For the sake of security, web browsers are not allowed access to host computers’ device storage. But to personalize certain features for users, web developers have been provided with temporary in-browser storage which everyone knows as cookies. Cookies are everywhere on the web. And for some time now, everyone has thought of cookies as bad whereas the original intent which led to the creation of cookies is in itself good: to personalize features for users.
为了安全起见，不允许Web浏览器访问主机计算机的设备存储。 但是为了为用户个性化某些功能，已经为Web开发人员提供了临时的浏览器内存储，每个人都将其称为Cookie。 Cookies在网络上无处不在。 一段时间以来，每个人都认为cookie不好，而导致创建cookie的最初意图本身就是好：为用户个性化功能。
For instance, to keep a user signed in to their favorite website so that they wouldn’t have to always sign in each time they visited the website, cookies are used to save the user’s ID after they sign in the first time. This is called a session, i.e, a session has been created for the user.
例如，为了使用户登录到自己喜欢的网站，以使他们不必每次访问该网站时都始终登录，cookie用来在用户首次登录后保存其ID。 这称为会话，即已为用户创建了会话。
Usually, signed in sessions are kept for days, depending on the developer's anxiety concerning the security of the website as it is in the cases of PayPal and stripe where cookies are very ephemeral to make users sign in often for security reasons.
通常，登录会话会保留几天，具体取决于开发人员对网站安全性的焦虑，就PayPal和Stripe而言，由于安全原因，Cookie非常容易使用户登录，因此PayPal和Stripe就是如此。
Another scenario where cookies come in handy is when a user saves a filter for a certain category of products to be shown to them every time they make a purchase on an e-commerce website, say a filter for Lenovo Thinkpad Laptops.
Cookie派上用场的另一种情况是，用户为每次在电子商务网站上进行购买时要显示给他们的某种产品类别保存过滤器，例如Lenovo Thinkpad Laptops的过滤器。
When something like that happens, as a developer you would set a cookie in the user’s browser like so:
当发生这种情况时，作为开发人员，您将在用户的浏览器中设置cookie，如下所示：
Set Cookie: Category=Electronics and Computers; Type=Computers; Details=Lenovo Thinkpad(Not exactly that, but just something in that form.)
(不完全是，只是某种形式。)
Now, when you set cookies, this is what happens in the background.
现在，当您设置Cookie时，这就是在后台发生的情况。
There are several properties you can set for a cookie. For example, SameSite property, Max-Age or Expiry time of the cookie, Secure property i.e whether the browser should use secure means to save and serve the cookie, path of the cookie, domain of the cookie, etc.
您可以为Cookie设置几个属性。 例如，SameSite属性，cookie的Max-Age或Expiry时间，Secure属性，即浏览器是否应使用安全方式保存和提供cookie，cookie的路径，cookie的域等。
All these properties decide how the browser can use the cookie, which websites can see it, how the browser protects the cookie, and where it saves it.
所有这些属性决定了浏览器如何使用cookie，哪些网站可以看到它，浏览器如何保护cookie以及将其保存在何处。
But the problem is that as developers, only some of the cookie properties above matter to us most, at least for a developer with not so much interest in web security.
但是问题在于，作为开发人员，至少对我们而言，以上的某些cookie属性最为重要，至少对于那些对网络安全性不太感兴趣的开发人员而言。
We tend to only set the cookie name and its value and an expiry time for the cookie, and then we leave all the rest to the browser to set its defaults for it.
我们倾向于只设置cookie名称，其值以及cookie的到期时间，然后将其余所有内容留给浏览器为其设置默认值。
What I did not know and possibly many developers out there did not know is this.
我不知道，也许很多开发人员都不知道的是这个。
Every time a website linked to a resource, like an image from another website, the cookies set on visitors browsers by the linked website would be sent to the linking website.
每当网站链接到资源(例如来自另一个网站的图像)时，由链接网站在访问者浏览器上设置的cookie都会发送到链接网站。
What it means is that virtually every cookie you set could be accessed by some other website’s servers. All they need to do is link to a resource on your website and wait for your users to visit their site.
这意味着实际上您设置的每个cookie都可以被其他网站的服务器访问。 他们所需要做的就是链接到您网站上的资源，并等待您的用户访问他们的网站。
Knowledge of this could be exploited to get access to unauthorized information to make certain exploits on websites.
可以利用此方面的知识来获取未经授权的信息，从而对网站进行某些利用。
Such exploits are known as Cross-site request forgery (CSRF).
这种漏洞被称为跨站点请求伪造(CSRF) 。
Imagine if you had saved your user’s password and username in a cookie and this happened. Catastrophy, huh…
想象一下，如果您已将用户的密码和用户名保存在cookie中，就会发生这种情况。 灾难性的，呵呵...
This is why we only save encrypted user IDs in cookies and never save a password in a cookie, whether encrypted or not.
这就是为什么我们仅将加密的用户ID保存在cookie中，而从不将密码保存在cookie中(无论是否加密)的原因。
But why should things work like this; why should everybody be able to access my cookies?
但是为什么事情应该这样工作？ 为什么每个人都可以访问我的cookie？
If you are asking this question, well it’s because we failed to learn. Yes, you and I, we failed to learn.
如果您在问这个问题，那是因为我们没有学习。 是的，您和我，我们都没有学习。
The SameSite property on cookies is what you can use to indicate whether you want your cookies to be delivered to other sites or not.
cookie上的SameSite属性是您可以用来指示是否希望将cookie传递到其他站点的属性。
But, we failed to know it, maybe because it was on our blind side. We were only interested in the functionality of our websites so we did not bother to set the property, and in return, the browser default is set to it, which is None — meaning serve my cookies to anybody.
但是，我们不知道它，也许是因为它在我们的视线一边。 我们只对网站的功能感兴趣，因此我们无需理会该属性，因此，将浏览器默认设置为该属性，即None ，这意味着向任何人提供我的cookie。
Other possible values that can be set include: Lax and Strict.
可以设置的其他可能值包括：“ Lax and Strict.
In the new Chrome 80 update, the property now requires that if you set None to it, you must also specify Secure as well. This means yes, you want the cookie to be delivered to other sites, but in a secure context only.
在新的Chrome 80更新中，该属性现在要求，如果将其设置为None ，则还必须指定Secure 。 这意味着可以，您希望将cookie传递到其他站点，但是仅在安全的上下文中。
See here for a more detailed explanation.
请参阅此处以获得更详细的说明。
更新如何可能破坏您的Angular应用程序 (How the Update Could Possibly Break Your Angular App)
To set cookies in my angular apps, I use the ngx-cookie-service library, which I believe several other Angular developers use too.
要在我的angular应用程序中设置cookie，我使用ngx-cookie-service库，我相信其他Angular开发人员也可以使用该库。
But, how I got to know about the chrome 80 update was that a website that I am the maintainer of broke on Google Chrome browsers. Meaning if you tried to sign in to the site from a Chrome browser, you wouldn’t be able to.
但是，我如何得知chrome 80更新的原因是我维护的网站在Google Chrome浏览器上崩溃了。 这意味着，如果您尝试通过Chrome浏览器登录该网站，则将无法登录。
This happened because ngx-cookie-service was no longer setting cookies correctly, which I realized after two days of inspection, research, and trials. Ngx-cookie-service has had a known issue setting cookies on Chrome browsers, but this issue was fixed.
发生这种情况是因为ngx-cookie-service不再正确设置cookie，这是经过两天的检查，研究和试验后才意识到的。 Ngx-cookie-service在设置Chrome浏览器上Ngx-cookie-service方面存在一个已知问题，但此问题已修复 。
The fix was to set cookies, making sure to set the path property to /. But it seems the fix does not work anymore with the Chrome 80 update. I do not know how correct I am on this, but I am opening an issue on it so that the devs can look into it again since the original issue was not really solved. It was only a workaround that was the fix to it.
解决方法是设置cookie，确保将path属性设置为/ 。 但是似乎该修复程序不适用于Chrome 80更新。 我不知道我对此有多正确，但是我正在就此问题进行开放 ，以便开发人员可以再次研究它，因为原始问题并未得到真正解决。 只是解决此问题的一种解决方法。
Just to be clear, I also tried updating the module to see if it had received a fix yet but that did not solve the problem.
为了清楚起见，我还尝试更新模块以查看其是否已收到修复程序，但这不能解决问题。
In the meantime, another workaround fix you can use until things get stable is to use the DOM object to set your cookies and then you can just access them using the normal ngx-cookie-service API.
同时，在情况稳定之前，可以使用的另一种解决方法是使用DOM对象设置cookie，然后可以使用常规的ngx-cookie-service API访问它们。
For example:
例如：
document.cookie = "userId=d123DujfOkxPxjsk234jwskksjd; Max-Age=${60*60*24}; SameSite=Strict";And then to access it you just use the ngx-cookie-service in your component.ts like so:
然后要访问它，只需在ngx-cookie-service使用ngx-cookie-service ，如下所示：
// Import ngx-cookie-service
import { CookieService } from 'ngx-cookie-service';// Inject the service
constructor(
private cookieService: CookieService
){ }// Read the cookie value
userId = this.cookieService.get("userId");更新如何破坏其他网站 (How the Update Could Break Every Other Website)
From my understanding, the Chrome 80 update could possibly require every developer or site maintainer to service their websites if they would still like to receive traffic from Google Chrome users.
据我了解，如果Chrome 80更新仍然希望接收来自Google Chrome用户的访问量，可能会要求每个开发人员或网站维护者为其网站提供服务。
For any website that uses cookies to serve personalized data and features to users, the update could break their sites.
对于使用Cookie为用户提供个性化数据和功能的任何网站，此更新可能会破坏他们的网站。
By default, without specifying any value for the SameSite property on cookies, the property would have been set as None. And if you did set it to none before, then surely your website is bound to break; by the chrome 80 update, the required value now is SameSite=None; Secure;.
默认情况下，如果不为cookie的SameSite属性指定任何值，则该属性将被设置为None 。 而且，如果您之前没有将其设置为“ none”，那么您的网站肯定会崩溃； 通过chrome 80更新，现在所需的值为SameSite=None; Secure; SameSite=None; Secure; 。
It is expected that the new default should become None; Secure; when no value is set for the SameSite property. The only problem is that older browsers do not have this implemented.
预期新的默认值应变为None; Secure; None; Secure; 如果没有为SameSite属性设置任何值。 唯一的问题是较旧的浏览器未实现此功能。
Google Chrome has it as default behaviour as of version 84, and Firefox has had it in testing as of Firefox 69.
Google Chrome从84版开始将其作为默认行为，而Firefox从Firefox 69版开始进行测试。
Older browsers, by default, set the SameSite property to None if you do not set the value explicitly. So, this will surely break your site if you do not change it.
如果未明确设置值，则较早的浏览器默认情况下会将SameSite属性设置为None 。 因此，如果不进行更改，这肯定会破坏您的网站。
It is also safer to explicitly state it rather than to hang around and hope for the best, because you probably are even using some library like ngx-cookie-service to set cookies on your site and you are not sure what value it is setting it to by default.
明确声明它而不是闲逛并希望获得最好的结果也更安全，因为您甚至可能正在使用ngx-cookie-service类的库来在您的网站上设置cookie，并且您不确定它设置了什么值默认情况下。
On GitHub, there is an open issue on the ngx-cookie-service repo opened by user axos88 requesting for the library devs to change the implementation of the ngx-cookie-service to make it explicitly state Lax when the SameSite value is not set.
在GitHub上，用户axos88打开了ngx-cookie-service 存储库上的一个未解决问题 ，要求库开发人员更改ngx-cookie-service的实现，以在未设置SameSite值时明确声明Lax 。
This is to give support for older browsers which would still be setting None for the value.
这是为了支持较旧的浏览器，该浏览器仍将值设置为None 。
So, with all this in mind, you just cannot say that users should just clear all cookies and update their browsers and everything would work again. You have to service the site and explicitly state what the SameSite value should be for all the cookies you set just so you are sure.
因此，考虑到所有这些，您不能说用户只应该清除所有cookie并更新他们的浏览器，然后一切都会恢复。 您必须为站点提供服务，并明确声明对于您设置的所有cookie的SameSite值应该是多少，以便确定。
Even if an update was made to ngx-cookie-service, you still have to go on to your site’s source code and update the version of the module that you’re using.
即使对ngx-cookie-service进行了更新，您仍然必须继续查看网站的源代码并更新所使用模块的版本。
So, just go and service your site just like this good boy minion is doing here…
因此，就像这个好孩子奴才在这里所做的那样，就去服务您的网站吧……
And take it easy, folks.
伙计们，放轻松点。
9925
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
