From e74bdb01471588920a2a8c367010cd694f13bf66 Mon Sep 17 00:00:00 2001 From: LeviDing Date: Sun, 12 Apr 2020 18:47:29 +0800 Subject: [PATCH 1/9] Update index.md --- 6-data-storage/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/6-data-storage/index.md b/6-data-storage/index.md index a08c05b580..e35f803464 100644 --- a/6-data-storage/index.md +++ b/6-data-storage/index.md @@ -1,2 +1,2 @@ -# Storing data in the browser +# 在浏览器中存储数据 From 618d3bf4a86861f51c3723d6c381c042d7ca7049 Mon Sep 17 00:00:00 2001 From: LeviDing Date: Sun, 12 Apr 2020 20:18:39 +0800 Subject: [PATCH 2/9] Update article.md --- 6-data-storage/01-cookie/article.md | 32 ++++++++++++++--------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/6-data-storage/01-cookie/article.md b/6-data-storage/01-cookie/article.md index 438bda7eb5..21d5728418 100644 --- a/6-data-storage/01-cookie/article.md +++ b/6-data-storage/01-cookie/article.md @@ -1,41 +1,41 @@ -# Cookies, document.cookie +# Cookie，document.cookie -cookies 是直接保存在浏览器上的小数据串。它们是 HTTP 协议的一部分，由 [RFC 6265](https://tools.ietf.org/html/rfc6265) 规范定义。 +Cookie 是直接存储在浏览器中的一小串数据。它们是 HTTP 协议的一部分，由 [RFC 6265](https://tools.ietf.org/html/rfc6265) 规范定义。 -大多数情况下，cookies 是由 web 服务器设置的。然后它们会自动添加到相同域名下的每次请求中。 +Cookie 通常是由网络服务器使用响应 `Set-Cookie` HTTP-header 设置的。然后浏览器使用 `Cookie` HTTP-header 将它们自动添加到（几乎）每个对相同域的请求中。 -最常见的用处之一是身份验证： +最常见的用处之一就是身份验证： -1. 登录后，服务端通过 `Set-Cookie` 在响应的 HTTP-header 中设置了一个带有 "会话标识符" 的 cookie。 -2. 下次如果相同域名发起了请求，浏览器会发送带有 `Cookie` 的 HTTP-header。 -3. 所以服务端知道是谁发起了请求。 +1. 登录后，服务器在响应中使用 `Set-Cookie` HTTP-header 来设置具有唯一“会话标识符”的 cookie。 +2. 下次如果请求是由相同域发起的，浏览器会使用 `Cookie` HTTP-header 通过网络发送 cookie。 +3. 所以服务器知道是谁发起了请求。 -我们还可以使用 `document.cookie` 属性在浏览器上访问 cookies。 +我们还可以使用 `document.cookie` 属性从浏览器访问 cookie。 -有关 cookies 和它们的选项有很多棘手的事情。在本章节中，我们将会详细介绍。 +关于 cookie 及其选项，有很多棘手的事情。在本章中，我们将详细介绍它们。 ## 从 document.cookie 中读取 ```online -你在这个网站上有 cookies 吗？让我们来看看： +你的浏览器是否存储了本网站的任何 cookie？让我们来看看： ``` ```offline -假设你在网站上可以看到 cookies，像这样： +假设你在一个网站上，则可以看到来自该网站的 cookie，像这样： ``` ```js run -// 在 javascript.info，我们使用谷歌分析来统计， -// 所以应该存在一些 cookies +// 在 javascript.info，我们使用谷歌分析来进行统计， +// 所以应该存在一些 cookie alert( document.cookie ); // cookie1=value1; cookie2=value2;... ``` -`document.cookie` 的值由一个个 `name=value` 组成，以 `; ` 相隔。每一个都是独立的 cookie。 +`document.cookie` 的值由 `name=value` 对组成，以 `; ` 分隔。每一个都是独立的 cookie。 -为了找到一个特定的 cookie，我们可以通过 `; ` 截取 `document.cookie`，然后找到合适的名字。我们可以使用正则表达式或者数组的方法来实现。 +为了找到一个特定的 cookie，我们可以以 `; ` 作为分隔，将 `document.cookie` 分开，然后找到对应的名字。我们可以使用正则表达式或者数组函数来实现。 -我们把这个留给读者当作练习。此外，在本章节的结尾，你可以找到一些操作 cookies 的辅助函数。 +我们把这个留给读者当作练习。此外，在本章的最后，你可以找到一些操作 cookie 的辅助函数。 ## 写入 document.cookie From 8dd5b3e7a62411f9b82fda2a515bd5a10667f279 Mon Sep 17 00:00:00 2001 From: LeviDing Date: Sun, 12 Apr 2020 20:22:12 +0800 Subject: [PATCH 3/9] Update task.md --- 6-data-storage/02-localstorage/1-form-autosave/task.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/6-data-storage/02-localstorage/1-form-autosave/task.md b/6-data-storage/02-localstorage/1-form-autosave/task.md index 9f667c7773..6071c23ac0 100644 --- a/6-data-storage/02-localstorage/1-form-autosave/task.md +++ b/6-data-storage/02-localstorage/1-form-autosave/task.md @@ -1,8 +1,9 @@ -# 自动保存表单域 -创建一个 `textarea`，每当值发生变化时，可以自动保存。 +# 自动保存表单字段 -因此，如果用户偶尔关闭了页面，然后重新打开，他会发现之前输入的值仍然保留着。 +创建一个 `textarea` 字段，每当其值发生变化时，可以将其“自动保存”。 + +因此，如果用户不小心关闭了页面，然后重新打开，他会发现之前未完成的输入仍然保留在那里。 像这样： From 5f766eaa6dda21512ec9b0ce1394c941ba9692f5 Mon Sep 17 00:00:00 2001 From: LeviDing Date: Sun, 12 Apr 2020 21:20:36 +0800 Subject: [PATCH 4/9] Update article.md --- 6-data-storage/01-cookie/article.md | 76 ++++++++++++++--------------- 1 file changed, 38 insertions(+), 38 deletions(-) diff --git a/6-data-storage/01-cookie/article.md b/6-data-storage/01-cookie/article.md index 21d5728418..804b46e16c 100644 --- a/6-data-storage/01-cookie/article.md +++ b/6-data-storage/01-cookie/article.md @@ -39,42 +39,42 @@ alert( document.cookie ); // cookie1=value1; cookie2=value2;... ## 写入 document.cookie -我们可以写入 `document.cookie`。但是这不是一个数据属性，它是一个访问者（getter/setter）。赋值操作会被特殊处理。 +我们可以写入 `document.cookie`。但这不是一个数据属性，它是一个访问器（getter/setter）。对其的赋值操作会被特殊处理。 -**浏览器的 `document.cookie` 写入操作只会更新已存在的 cookies，而不会影响其他 cookies。** +**对 `document.cookie` 的写入操作只会更新其中提到的 cookie，而不会涉及其他 cookie。** -例如，这里设置了一个名称为 `user` 和值为 `John` 的 cookie： +例如，此调用设置了一个名称为 `user` 且值为 `John` 的 cookie： ```js run document.cookie = "user=John"; // 只会更新名称为 user 的 cookie -alert(document.cookie); // 展示所有 cookies +alert(document.cookie); // 展示所有 cookie ``` -如果你运行了代码，你很可能会看到多个 cookies。这是因为 `document.cookie=` 操作不是重写整个 cookies。它只设置代码中提到的 cookie `user`。 +如果你运行了上面这段代码，你会看到多个 cookie。这是因为 `document.cookie=` 操作不是重写整所有 cookie。它只设置代码中提到的 cookie `user`。 -从技术层面看，cookie 的名称和值能是任何字符，为了保持格式有效，它们应该使用 `encodeURIComponent` 内置方法来编码一下： +从技术上讲，cookie 的名称和值可以是任何字符，为了保持有效的格式，它们应该使用内建的 `encodeURIComponent` 函数对其进行转义： ```js run -// 特殊字符（空白符），需要编码 +// 特殊字符（空格），需要编码 let name = "my name"; let value = "John Smith" -// 编码后变成 my%20name=John%20Smith +// 将 cookie 编码为 my%20name=John%20Smith document.cookie = encodeURIComponent(name) + '=' + encodeURIComponent(value); alert(document.cookie); // ...; my%20name=John%20Smith ``` -```warn header="局限性" -存在一些局限性： -- `encodeURIComponent` 编码后的 `name=value` 对，大小不能超过 4kb。所以我们不能在一个 cookie 中保存大数据。 -- 每个域名下所有 cookies 的总数限制在 20 几个，实际的限制数量取决于浏览器。 +```warn header="限制" +存在一些限制： +- `encodeURIComponent` 编码后的 `name=value` 对，大小不能超过 4kb。因此，我们不能在一个 cookie 中保存大的东西。 +- 每个域的 cookie 总数不得超过 20+ 左右，具体限制取决于浏览器。 ``` -cookies 有好几个选项，很多选项都很重要并且应该设置它。 +Cookie 有几个选项，其中很多都很重要，应该设置它。 -选项列在 `key=value` 后面，使用 `;` 间隔，像这样： +选项被列在 `key=value` 之后，以 `;` 分隔，像这样： ```js run document.cookie = "user=John; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT" @@ -84,21 +84,21 @@ document.cookie = "user=John; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT" - **`path=/mypath`** -可访问到 cookie 的 url 路径前缀。必须是绝对路径。默认值为当前路径。 +url 路径前缀，该路径下的页面可以访问该 cookie。必须是绝对路径。默认为当前路径。 -如果一个 cookie 设置了 `path=/admin`，那么在 `/admin` 和 `/admin/something` 下都是可见的，但是在 `/home` 或 `/adminpage` 下不可见。 +如果一个 cookie 带有 `path=/admin` 设置，那么该 cookie 在 `/admin` 和 `/admin/something` 下都是可见的，但是在 `/home` 或 `/adminpage` 下不可见。 -通常，我们设置 `path=/` 来允许网站下所有页面访问 cookie。 +通常，我们应该将 `path` 设置为根目录：`path=/`，以使 cookie 对此网站的所有页面可见。 ## domain - **`domain=site.com`** -可访问到 cookie 的域名。但是在实践中，存在局限性。我们不能设置任何域名。 +可访问 cookie 的域。但是在实际中，有一些限制。我们无法设置任何域。 -默认情况下，cookie 只能在设置的域名下才能访问到。所以，如果 cookie 设置在 `site.com` 下，我们不能在任何其他域名下（`other.com`）访问它。 +默认情况下，cookie 只有在设置的域下才能被访问到。所以，如果 cookie 设置在 `site.com` 下，我们在 `other.com` 下就无法获取它。 -……但是棘手的是，我们在子域名下同样不能获取到 cookie（`forum.site.com`）！ +……但是棘手的是，我们在子域 `forum.site.com` 下也无法获取它！ ```js // 在 site.com @@ -108,28 +108,28 @@ document.cookie = "user=John" alert(document.cookie); // 没有 user ``` -**让 cookie 在另外一个二级域名下可以访问到是没有办法的，所以其他域名 `other.com` 将不会接收到设置在 `site.com` 的 cookie。** +**无法使 cookie 可以被从另一个二级域访问，因此，`other.com` 将永远不会收到设置在 `site.com` 的 cookie。** -这是一个安全限制，为了允许我们可以在 cookie 中保存敏感信息。 +这是一项安全限制，为了允许我们可以将敏感信息保存在 cookie 中。 -……但是如果我们想要批准像 `forum.site.com` 这样的子域名访问，这是可以做到的。我们应该明确设置 `domain` 选项为根域名：`domain=site.com`： +……但是，如果我们想要批准像 `forum.site.com` 这样的子域访问 cookie，这是可以做到的。当我们设置一个在 `site.com` 的 cookie 时，我们应该将 `domain` 选项显式地设置为根域：`domain=site.com`： ```js -// 在 site.com 中 -// 使 cookie 在其任何子域名下可以访问： +// 在 site.com +// 使 cookie 可以被在任何子域 *.site.com 访问： document.cookie = "user=John; domain=site.com" // 之后 // 在 forum.site.com -alert(document.cookie); // 也存在 user +alert(document.cookie); // 有 cookie user=John ``` -因为历史原因，`domain=.site.com`（以点开头）也可以正常使用，最好添加点来支持老版本的浏览器。 +出于历史原因，`domain=.site.com`（`site.com` 前面有一个点符号）也以相同的方式工作，允许从子域访问 cookie。这是一个旧的表示法，如果我们需要支持非常旧的浏览器，则应该使用它。 -所以，`domain` 选项允许子域名访问 cookie。 +所以，`domain` 选项允许设置一个可以在子域访问的 cookie。 -## expires, max-age +## expires，max-age 默认情况下，如果一个 cookie 没有设置这两个参数中的任何一个，那么在浏览器关闭后，它就会消失。此类 cookies 被称为 "session cookies”。 @@ -172,9 +172,9 @@ cookie 应仅在 HTTPS 环境下传输。 **默认情况下，如果我们在 `http://site.com` 设置了 cookie，然后 cookie 在 `https://site.com` 中也会出现，反之亦然。** -也就是说，cookies 是基于域名的，它们不是通过协议来区分的。 +也就是说，cookies 是基于域的，它们不是通过协议来区分的。 -有了这个选项，如果一个 cookie 通过 `https://site.com` 设置，然后它不会在相同域名的 HTTP 环境下出现，例如 `http://site.com`。所以，如果一个 cookie 存有敏感内容，不应该在不安全的 HTTP 环境下发送，此时这个选项就派上用场了。 +有了这个选项，如果一个 cookie 通过 `https://site.com` 设置，然后它不会在相同域的 HTTP 环境下出现，例如 `http://site.com`。所以，如果一个 cookie 存有敏感内容，不应该在不安全的 HTTP 环境下发送，此时这个选项就派上用场了。 ```js // 假设我们现在在 HTTPS 环境下 @@ -214,7 +214,7 @@ cookie 的 `samesite` 选项提供了另一种防止此类攻击的方法，（ 如果用户来自同一站点之外，那么设置了 `samesite=strict` 的 cookie 永远不会发送。 -换句话说，无论用户是跟踪邮件链接或从 `evil.com` 提交表单，或者来自其他域名下的任何操作，cookie 都不会发送。 +换句话说，无论用户是跟踪邮件链接或从 `evil.com` 提交表单，或者来自其他域下的任何操作，cookie 都不会发送。 如果身份验证的 cookies 存在 `samesite` 选项，XSRF 攻击是没有机会成功的，因为 `evil.com` 发起的提交没有 cookies。所以 `bank.com` 无法识别用户，并且不会继续付款。 @@ -344,7 +344,7 @@ function deleteCookie(name) { ``` ```warn header="Updating or deleting must use same path and domain" -请注意：当我们更新或者删除一个 cookie 时，我们应该使用和设置 cookie 时相同的路径和域名选项。 +请注意：当我们更新或者删除一个 cookie 时，我们应该使用和设置 cookie 时相同的路径和域选项。 ``` 代码放在: [cookie.js](cookie.js). @@ -352,11 +352,11 @@ function deleteCookie(name) { ## 附录：第三方 cookies -如果 cookie 在用户正在访问的页面外的域名网站设置，则被称为第三方 cookie。 +如果 cookie 在用户正在访问的页面外的域网站设置，则被称为第三方 cookie。 例如： 1. `site.com` 网站的一个页面加载了另外一个网站的 banner：``。 -2. 和 banner 一起，`ads.com` 的远程服务器可能设置 `Set-Cookie` 标头比如 `id=1234`。此类 cookie 源自 `ads.com` 域名，并且只在 `ads.com` 下是可见的： +2. 和 banner 一起，`ads.com` 的远程服务器可能设置 `Set-Cookie` 标头比如 `id=1234`。此类 cookie 源自 `ads.com` 域，并且只在 `ads.com` 下是可见的： ![](cookie-third-party.svg) @@ -369,13 +369,13 @@ function deleteCookie(name) { ![](cookie-third-party-3.svg) -由于它的性质，第三方 cookies 传统上用于跟踪和广告服务。它们绑定在原始域名上，因此 `ads.com` 可以跟踪到不同站点下的相同用户，如果他们访问的话。 +由于它的性质，第三方 cookies 传统上用于跟踪和广告服务。它们绑定在原始域上，因此 `ads.com` 可以跟踪到不同站点下的相同用户，如果他们访问的话。 当然，一些用户不喜欢被跟踪，所以浏览器禁止此类 cookies。 此外，一些现代浏览器对此类 cookies 采用特殊策略： - Safari 浏览器根本不允许第三方 cookies。 -- Firefox 浏览器附带一个第三方域名的黑名单，可以阻止第三方 cookies。 +- Firefox 浏览器附带一个第三方域的黑名单，可以阻止第三方 cookies。 ```smart @@ -419,7 +419,7 @@ GDPR 不仅只涉及 cookie，还涉及其他与隐私相关的问题，但这 Cookie 选项： - `path=/`，默认为当前路径，使 cookie 仅在该路径下可见。 -- `domain=site.com`，默认 cookie 仅在当前域名下可见，如果明确设置了域名，可以让 cookie 在子域名下也可见。 +- `domain=site.com`，默认 cookie 仅在当前域下可见，如果明确设置了域，可以让 cookie 在子域下也可见。 - `expires` 或 `max-age` 设置 cookie 过期时间，如果没有设置，则当浏览器关闭时 cookie 就失效了。 - `secure` 使 cookie 仅在 HTTPS 下有效。 - `samesite` 如果请求来自外部网站，禁止浏览器发送 cookie，这样有助于防止 XSRF 攻击。 From 682ded19a05ac24637dcccce70fd59117cfcfb0f Mon Sep 17 00:00:00 2001 From: LeviDing Date: Sun, 12 Apr 2020 22:08:27 +0800 Subject: [PATCH 5/9] Update article.md --- 6-data-storage/01-cookie/article.md | 36 ++++++++++++++--------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/6-data-storage/01-cookie/article.md b/6-data-storage/01-cookie/article.md index 804b46e16c..2016678af6 100644 --- a/6-data-storage/01-cookie/article.md +++ b/6-data-storage/01-cookie/article.md @@ -131,62 +131,62 @@ alert(document.cookie); // 有 cookie user=John ## expires，max-age -默认情况下，如果一个 cookie 没有设置这两个参数中的任何一个，那么在浏览器关闭后，它就会消失。此类 cookies 被称为 "session cookies”。 +默认情况下，如果一个 cookie 没有设置这两个参数中的任何一个，那么在关闭浏览器之后，它就会消失。此类 cookie 被称为 "session cookie”。 -为了让 cookies 在浏览器关闭后仍然存在，我们可以设置 `expires` 或 `max-age` 其中一个选项。 +为了让 cookie 在浏览器关闭后仍然存在，我们可以设置 `expires` 或 `max-age` 选项中的一个。 - **`expires=Tue, 19 Jan 2038 03:14:07 GMT`** -cookie 过期日期，当到了过期时间浏览器会自动删除它。 +cookie 的到期日期，那时浏览器会自动删除它。 -日期必须是这种格式，GMT 时区。我们可以使用 `date.toUTCString` 方法得到。举个例子，我们可以设置 cookie 在 1 天后过期。 +日期必须完全采用 GMT 时区的这种格式。我们可以使用 `date.toUTCString` 来获取它。例如，我们可以将 cookie 设置为 1 天后过期。 ```js -// 在当前时间上加 1 天 +// 当前时间 +1 天 let date = new Date(Date.now() + 86400e3); date = date.toUTCString(); document.cookie = "user=John; expires=" + date; ``` -如果我们设置 `expires` 为已经过去的时间，cookie 会被删除。 +如果我们将 `expires` 设置为过去的时间，则 cookie 会被删除。 - **`max-age=3600`** -一个可以替代 `expires` 的选项，具体说明 cookie 的过期时间距离当前时间的秒数。 +`expires` 的替代选项，具指明 cookie 的过期时间距离当前时间的秒数。 -如果是 0 或者负数，cookie 会被删除： +如果为 0 或负数，则 cookie 会被删除： ```js -// 1 小时后 cookie 会失效 +// cookie 会在一小时后失效 document.cookie = "user=John; max-age=3600"; -// 删除 cookie (让 cookie 马上过期) +// 删除 cookie（让它立即过期） document.cookie = "user=John; max-age=0"; -``` +``` ## secure - **`secure`** -cookie 应仅在 HTTPS 环境下传输。 +Cookie 应只能被通过 HTTPS 传输。 -**默认情况下，如果我们在 `http://site.com` 设置了 cookie，然后 cookie 在 `https://site.com` 中也会出现，反之亦然。** +**默认情况下，如果我们在 `http://site.com` 上设置了 cookie，那么该 cookie 也会出现在 `https://site.com` 上，反之亦然。** -也就是说，cookies 是基于域的，它们不是通过协议来区分的。 +也就是说，cookie 是基于域的，它们不区分协议。 -有了这个选项，如果一个 cookie 通过 `https://site.com` 设置，然后它不会在相同域的 HTTP 环境下出现，例如 `http://site.com`。所以，如果一个 cookie 存有敏感内容，不应该在不安全的 HTTP 环境下发送，此时这个选项就派上用场了。 +使用此选项，如果一个 cookie 是通过 `https://site.com` 设置的，那么它不会在相同域的 HTTP 环境下出现，例如 `http://site.com`。所以，如果一个 cookie 包含绝不应该通过未加密的 HTTP 协议发送的敏感内容，那么就应该设置这个选项。 ```js // 假设我们现在在 HTTPS 环境下 -// 设置 cookie secure（只在 HTTPS 环境下传输） +// 设置 cookie secure（只在 HTTPS 环境下可访问） document.cookie = "user=John; secure"; ``` ## samesite -这是另外一个关于安全的选项，为了防止 XSRF（跨站点请求伪造）攻击。 +这是另外一个关于安全的特性。它旨在防止 XSRF（跨站点请求伪造）攻击。 -为了理解它什么时候起效，我们来介绍下以下的攻击情况。 +为了了解它是如何工作的，以及何时有用，让我们看一下 XSRF 攻击。 ### XSRF 攻击 From 7cbae733c20f2777c0e0bd098df9fe9032351136 Mon Sep 17 00:00:00 2001 From: LeviDing Date: Sun, 12 Apr 2020 23:29:44 +0800 Subject: [PATCH 6/9] Update article.md --- 6-data-storage/01-cookie/article.md | 50 ++++++++++++++--------------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/6-data-storage/01-cookie/article.md b/6-data-storage/01-cookie/article.md index 2016678af6..67e03ce6dc 100644 --- a/6-data-storage/01-cookie/article.md +++ b/6-data-storage/01-cookie/article.md @@ -184,62 +184,62 @@ document.cookie = "user=John; secure"; ## samesite -这是另外一个关于安全的特性。它旨在防止 XSRF（跨站点请求伪造）攻击。 +这是另外一个关于安全的特性。它旨在防止 XSRF（跨网站请求伪造）攻击。 为了了解它是如何工作的，以及何时有用，让我们看一下 XSRF 攻击。 ### XSRF 攻击 -想象一下，你登录了 `bank.com` 网站。此时：你有了该站点的身份验证 cookie。你的浏览器会随着每次请求把它发送到 `bank.com`，因此，`bank.com` 承认你的身份和你做出的所有敏感经济操作。 +想象一下，你登录了 `bank.com` 网站。此时：你有了来自该网站的身份验证 cookie。你的浏览器会在每次请求时将其发送到 `bank.com`，以便识别你，并执行所有敏感的财务上的操作。 -现在，在另外一个窗口浏览网页时，你偶然访问了另外一个网站 `evil.com`，该网站有 JavaScript 代码提交了一个表单 `
` 到 `bank.com`，提交的表单字段能够开始一笔到黑客账户的交易。 +现在，在另外一个窗口中浏览网页时，你不小心访问了另一个网站 `evil.com`。该网站具有向 `bank.com` 网站提交一个具有启动与黑客账户交易的字段的表单 `` 的 JavaScript 代码。 -你每次访问 `bank.com` 时 cookie 都会发送，即使表单在 `evil.com` 上提交。所以银行识别你的身份并实际执行付款。 +你每次访问 `bank.com` 时，浏览器都会发送 cookie，即使该表单是从 `evil.com` 提交过来的。因此，银行会识别你的身份，并执行真实的付款。 ![](cookie-xsrf.svg) -这就被称为一个跨站点请求伪造（Cross-Site Request Forgery，简称 XSRF）攻击。 +这就是“跨网站请求伪造（Cross-Site Request Forgery，简称 XSRF）”攻击。 -当然，真正的银行会防止出现这种情况。所有 `bank.com` 生成的表单都有一个特殊的字段，所谓的 "xsrf 保护令牌”，邪恶页面既不能生成或者从远程页面获取（它可以在那里提交表单，但是无法获取数据）。而且站点 `bank.com` 每次都会检查收到的表单上的令牌。 +当然，实际的银行会防止出现这种情况。所有由 `bank.com` 生成的表单都具有一个特殊的字段，即所谓的 “XSRF 保护令牌”，恶意页面既不能生成，也不能从远程页面提取它（它可以在那里提交表单，但是无法获取数据）。并且，网站 `bank.com` 会对收到的每个表单都进行这种令牌的检查。 -但这种防护需要时间来实现：我们需要确保每个表单都有 token 字段，而且必须检查所有的请求。 +但是，实现这种防护需要花费时间：我们需要确保每个表单都具有 token 字段，并且还必须检查所有请求。 ### 输入 cookie samesite 选项 -cookie 的 `samesite` 选项提供了另一种防止此类攻击的方法，（理论上）应该不需要 "xsrf 保护令牌”。 +Cookie 的 `samesite` 选项提供了另一种防止此类攻击的方式，（理论上）不需要要求 “XSRF 保护令牌”。 -它有两个可选的值： +它有两个可能的值： -- **`samesite=strict` (和 `samesite` 没有值一样)** +- **`samesite=strict`（和没有值的 `samesite` 一样)** -如果用户来自同一站点之外，那么设置了 `samesite=strict` 的 cookie 永远不会发送。 +如果用户来自同一网站之外，那么设置了 `samesite=strict` 的 cookie 永远不会被发送。 -换句话说，无论用户是跟踪邮件链接或从 `evil.com` 提交表单，或者来自其他域下的任何操作，cookie 都不会发送。 +换句话说，无论用户是通过邮件链接还是从 `evil.com` 提交表单，或者进行了任何来自其他域下的操作，cookie 都不会被发送。 -如果身份验证的 cookies 存在 `samesite` 选项，XSRF 攻击是没有机会成功的，因为 `evil.com` 发起的提交没有 cookies。所以 `bank.com` 无法识别用户，并且不会继续付款。 +如果身份验证 cookie 具有 `samesite` 选项，那么 XSRF 攻击是没有机会成功的，因为来自 `evil.com` 的提交没有 cookie。因此，`bank.com` 将无法识别用户，也就不会继续进行付款。 -保护非常有效。只有来自 `bank.com` 的操作才会发送 `samesite` cookie，例如来自 `bank.com` 上另一页面的表单发送。 +这种保护是相当可靠的。只有来自 `bank.com` 的操作才会发送 `samesite` cookie，例如来自 `bank.com` 的另一页面的表单提交。 -虽然，这样有一点点不方便。 +虽然，这样有一些不方便。 -当用户跟随合法链接来到 `bank.com`，例如他们自己的笔记，他们会感到惊讶，`bank.com` 不能识别他们的身份。实际上，在这种情况下 `samesite=strict` cookies 不会发送。 +当用户通过合法的链接访问 `bank.com` 时，例如从他们自己的笔记，他们会感到惊讶，`bank.com` 无法识别他们的身份。实际上，在这种情况下不会发送 `samesite=strict` cookie。 -我们可以使用两个 cookies 来解决这个问题：一个 cookie 用来 "大致识别"，仅用来说 "Hello, John"，另外一个带有 `samesite=strict` 的 cookie 用来验证数据改变的操作。然后来自外部网站的用户会看到欢迎页面，但必须在银行的网站上发起付款，为了第二个 cookie 能被发送。 +我们可以通过使用两个 cookie 来解决这个问题：一个 cookie 用于“一般识别”，仅用于说 "Hello, John"，另一个带有 `samesite=strict` 的 cookie 用于进行数据更改的操作。这样，从网站外部来的用户会看到欢迎信息，但是支付操作必须是从银行网站启动的，这样第二个 cookie 才能被发送。 - **`samesite=lax`** -一种更轻松的方法也能防止 XSRF 攻击并且不会破坏用户体验。 +一种更轻松的方法，该方法还可以防止 XSRF 攻击，并且不会破坏用户体验。 -lax 模式，和 `strict` 模式类似，禁止浏览器发送来自外部网站的 cookie，但是增加了一个例外。 +宽松（lax）模式，和 `strict` 模式类似，当从外部来到网站，则禁止浏览器发送 cookie，但是增加了一个例外。 -`samesite=lax` cookie 在以下两个条件都成立时会被发送： -1. HTTP 方法是安全的（例如 GET 方法，不是 POST）。 +如果以下两个条件均为 true，则会发送 `samesite=lax` cookie： +1. HTTP 方法是“安全的”（例如 GET 方法，而不是 POST）。 - 所有安全的 HTTP 方法列表可以看 [RFC7231 规范](https://tools.ietf.org/html/rfc7231)。基本上，这些都是只能用来读取数据但是不能写入数据的方法。他们不能执行任何更改数据的操作。以下链接都是 GET 安全方法。 + 所有安全的 HTTP 方法详见 [RFC7231 规范](https://tools.ietf.org/html/rfc7231)。基本上，这些都是用于读取而不是写入数据的方法。它们不得执行任何更改数据的操作。跟随链接始终是 GET，是安全的方法。 -2. 操作执行顶级导航（在浏览器地址栏中改变 URL）。 +2. 该操作执行顶级导航（更改浏览器地址栏中的 URL）。 - 这通常是正确的，但是如果导航是在一个 `