tough-cookie Node.js 的 RFC6265 Cookie 和 CookieJar 实现

Question

概要

var tough = require('tough-cookie');
var Cookie = tough.Cookie;
var cookie = Cookie.parse(header);
cookie.value = 'somethingdifferent';
header = cookie.toString();

var cookiejar = new tough.CookieJar();
cookiejar.setCookie(cookie, 'http://currentdomain.example.com/path', cb);
// ...
cookiejar.getCookies('http://example.com/otherpath',function(err,cookies) {
  res.headers['cookie'] = cookies.join('; ');
});

安装

安装 tough-cookie 非常的简单，只需要执行下面的代码：

npm install tough-cookie

为什么叫这个名字？NPM 模块 cookie，cookies 并且 cookiejar 已经被采用。

版本支持

对 node.js 版本的支持将遵循 request 模块的版本。

应用程序接口

tough

您从require('tough-cookie'). 所有都可以用作纯函数，不需要“绑定”。

注意：在 1.0.x 之前，这些函数中有几个带有strict参数。这已从 API 中删除，因为它不再是必要的。

parseDate(string)

将 cookie 日期字符串解析为Date. 根据 RFC6265 Section 5.1.1 解析，而不是Date.parse().

formatDate(date)

将日期格式化为 RFC1123 字符串（RFC6265 推荐格式）。

canonicalDomain(str)

将域名转换为规范域名。规范域名是经过修剪、小写、去除前导点和可选的 punycode 编码的域名（RFC6265 的第 5.1.2 节）。在大多数情况下，此函数是幂等的（可以在其输出上再次运行而不会产生不良影响）。

domainMatch(str,domStr[,canonicalize=true])

回答“这个真实的域是否与 cookie 中的域匹配？”。该str是“当前”域名和domStr是“曲奇”域名。根据 RFC6265 第 5.1.3 节进行匹配，但将其视为“后缀匹配”会有所帮助。

该canonicalize参数将运行其他两个参数是否通过canonicalDomain。

defaultPath(path)

给定当前的请求/响应路径，给出适合存储在 cookie 中的路径。这基本上是路径中“文件”的“目录”，但由 RFC 的第 5.1.4 节指定。

所述path参数必须是唯一一个URI的路径名部分（即不包括主机名，查询，片段等）。这是.pathname节点uri.parse()输出的属性。

pathMatch(reqPath,cookiePath)

回答“请求路径路径是否与给定的 cookie 路径匹配？” 根据 RFC6265 第 5.1.4 节。返回一个布尔值。

这本质上cookiePath是一个前缀匹配，其中是 的前缀reqPath。

parse(cookieString[, options])

别名为 Cookie.parse(cookieString[, options])

fromJSON(string)

别名为 Cookie.fromJSON(string)

getPublicSuffix(hostname)

返回此主机名的公共后缀。公共后缀是可以设置 cookie 的最短域名。返回null如果主机名不能为它设置的Cookie。

例如：www.example.com并且www.subdomain.example.com两者都有公共后缀example.com。

有关更多信息，请参阅http://publicsuffix.org/。该模块从该站点派生其列表。此调用目前是psl的get() 方法的包装器。

cookieCompare(a,b)

对于与 一起使用.sort()，将 cookie 列表按 RFC 中给出的推荐顺序进行排序（第 5.4 节第 2 步）。排序算法是，按优先顺序：

• 最长 .path
• 最旧.creation（精度为 1ms，与 相同Date）
• 最低.creationIndex（超过 1ms 精度）

var cookies = [ /* unsorted array of Cookie objects */ ];
cookies = cookies.sort(cookieCompare);

注意：由于 JavaScript 的Date精度限制为 1 毫秒，因此完全有可能在同一毫秒内生成 cookie。使用now选项时尤其如此.setCookie()。该.creationIndex属性是每个进程的全局计数器，在构造过程中使用new Cookie(). 这保留了 RFC 排序的精神：较旧的 cookie 先行。这对 很有用MemoryCookieStore，因为Set-Cookie头是按顺序解析的，但对于分布式系统可能不太好。复杂的Stores 可能希望将其设置为某个其他逻辑时钟，以便如果 cookie A 和 B 在同一毫秒内创建，但 cookie A 在 cookie B 之前创建，则A.creationIndex < B.creationIndex. 如果您想更改全局计数器，您可能不应该这样做做，它存储在Cookie.cookiesCreated.

permuteDomain(domain)

生成domainMatch()参数的所有可能域的列表。可能有助于实现 cookie 存储。

permutePath(path)

生成pathMatch()参数的所有可能路径的列表。可能有助于实现 cookie 存储。

Cookie

通过tough.Cookie.

Cookie.parse(cookieString[, options])

将单个 Cookie 或 Set-Cookie HTTP 标头解析为一个Cookie对象。undefined如果无法解析字符串，则返回。

options 参数不是必需的，目前只有一个属性：

• 松散- 布尔值 - 如果true启用无密钥 cookie 的解析，如=abc和=，它们不符合 RFC 规范。

如果 options 不是一个对象，它会被忽略，这意味着您可以使用Array#map它。

以下是如何处理节点 HTTP/HTTPS 响应上的 Set-Cookie 标头：

if (res.headers['set-cookie'] instanceof Array)
  cookies = res.headers['set-cookie'].map(Cookie.parse);
else
  cookies = [Cookie.parse(res.headers['set-cookie'])];

注意：在 2.3.3 版本中，tough-cookie 将 前面的空格数限制=为 256 个字符。此限制已被删除。见第 92 期

特性

Cookie 对象属性：

• key - 字符串 - cookie 的名称或键（默认为“”）
• value - string - cookie 的值（默认为 ""）
• expires - Date- 如果设置，则为Expires=cookie的属性（默认为 string "Infinity"）。看setExpires()
• maxAge - seconds - 如果设置，cookie的Max-Age=属性（以秒为单位）。也可以分别设置为字符串"Infinity"和"-Infinity"非到期和立即到期。看setMaxAge()
• domain - string - Domain=cookie的属性
• path - 字符串 - Path=cookie 的
• secure - 布尔 - Securecookie 标志
• httpOnly - 布尔值 - HttpOnlycookie 标志
• sameSite - 字符串 - SameSitecookie 属性（来自 [RFC6265bis]）；必须是一个none，lax或strict
• extensions - Array- 任何无法识别的 cookie 属性作为字符串（即使里面有等号）
• creation - Date- 构建此 cookie 时
• creationIndex - number - 在构造时设置，用于提供更高的排序精度（请参阅cookieCompare(a,b)完整说明）

传递 cookie 后 CookieJar.setCookie()，它将具有以下附加属性：

• hostOnly - 布尔值 - 这是一个仅限主机的 cookie（即没有设置域字段，而是隐含的）
• pathIsDefault - 布尔值 - 如果为 true，则 cookie 上没有 Path 字段并defaultPath()用于派生一个。
• creation - Date-修改施工时加入 Cookie 的罐子
• lastAccessed -Date上次访问 cookie 的时间。一旦实施将影响cookie清理。使用cookiejar.getCookies(...)将更新此属性。

Cookie([{properties}])

接收可以包含任何上述 Cookie 属性的选项对象，对未指定的属性使用默认值。

.toString()

编码为 Set-Cookie 标头值。Expires cookie 字段使用 设置formatDate()，但如果.expires是则完全省略Infinity。

.cookieString()

编码为 Cookie 标头值（即用“=”连接的.key和.value属性）。

.setExpires(String)

根据传递的日期字符串设置到期时间parseDate()。如果 parseDate 返回null（即无法解析此日期字符串），.expires则设置为"Infinity"（字符串）。

.setMaxAge(number)

以秒为单位设置 maxAge。强制-Infinity到"-Infinity"和Infinity到"Infinity"所以它 JSON 正确序列化。

.expiryTime([now=Date.now()])

.expiryDate([now=Date.now()])

expiryTime() 计算此 cookie 过期的绝对 unix-epoch 毫秒。expiryDate() 的工作原理类似，只是它返回一个Date对象。请注意，在这两种情况下，now参数都应为毫秒。

Max-Age 优先于 Expires（根据 RFC）。的.creation属性-或者，默认情况下，now参数-被用于抵消.maxAge属性。

如果.expires设置了Expires ( )，则返回。

否则，expiryTime()返回Infinity并expiryDate()返回Date“Tue, 19 Jan 2038 03:14:07 GMT”的对象（可以用 32 位表示的最新日期time_t；大多数用户代理的常见限制）。

.TTL([now=Date.now()])

计算相对于now（毫秒）的 TTL 。与expiryTime/ expiryDateapply相同的优先规则。

Infinity没有明确过期的 cookie 将返回“数字” ，0如果 cookie 已过期，则返回“数字” 。否则返回以毫秒为单位的生存时间。

.canonicalizedDomain()

.cdomain()

返回规范化的.domain字段。如果域有任何非 ASCII 字符，则这是小写和 punycode (RFC3490) 编码。

.toJSON()

为方便使用JSON.serialize(cookie)。返回一个Object可以被 JSON 序列化的普通的。

任何Date属性（即 、.expires、.creation和.lastAccessed）都以 ISO 格式 ( .toISOString())导出。

注意：自定义Cookie属性将被丢弃。在tough-cookie 1.x 中，由于没有.toJSON明确定义方法，因此捕获了所有可枚举的属性。如果要序列化属性，请将属性名称添加到Cookie.serializablePropertiesArray。

Cookie.fromJSON(strOrObj)

是否相反cookie.toJSON()。如果传递一个字符串，将JSON.parse()首先。

任何Date属性（即 、.expires、.creation和.lastAccessed）都通过Date.parse()而非tough-cookie进行解析parseDate，因为在这一层处理的是 JavaScript/JSON-y 时间戳。

nullJSON 解析错误时返回。

.clone()

对这个 cookie 进行深度克隆，完全实现为Cookie.fromJSON(cookie.toJSON()).

.validate()

状态：IN PROGRESS。适用于一些事情，但绝不是全面的。

验证 cookie 属性的语义正确性。用于“lint”检查您生成的任何 Set-Cookie 标头。现在，它返回一个布尔值，但最终可以返回一个原因字符串——你可以使用这个构造来验证未来：

if (cookie.validate() === true) {
  // it's tasty
} else {
  // yuck!
}

CookieJar

通过tough.CookieJar.

CookieJar([store],[options])

只需使用new CookieJar(). 如果您想使用自定义存储，请将其传递给构造函数，否则MemoryCookieStore将创建和使用 a。

该options对象可以省略，并且可以具有以下属性：

• rejectPublicSuffixes - 布尔值 - 默认值true- 拒绝带有“com”和“co.uk”等域的 cookie
• looseMode - 布尔值 - 默认值false- 接受格式不正确的 cookie，如bar和=bar，它们具有隐含的空名称。
• prefixSecurity -字符串-默认silent-设置为'unsafe-disabled'，'silent'或'strict'。请参阅下面的 [Cookie 前缀]。
• allowSpecialUseDomain - 布尔值 - 默认false- 接受特殊用途的域后缀，例如local. 用于测试目的。这不在标准中，但有时在网络上使用并且被（大多数）浏览器接受。

由于最终该模块希望支持数据库/远程/等。CookieJars，继续传递样式用于 CookieJar 方法。

.setCookie(cookieOrString, currentUrl, [{options},] cb(err,cookie))

尝试在 cookie jar 中设置 cookie。如果操作失败，回调会报错cb，否则传递cookie。cookie 将更新.creation,.lastAccessed和.hostOnly属性。

该options对象可以省略，并且可以具有以下属性：

• http - 布尔值 - 默认值true- 指示这是 HTTP 还是非 HTTP API。影响 HttpOnly cookie。
• 安全- 布尔值 - 从 url 自动检测 - 指示这是否是“安全”API。如果 currentUrl 以https:或开头，wss:则默认为true，否则为false。
• 现在- 日期 - 默认new Date()- 用于创建/访问 cookie 的时间
• ignoreError - 布尔值 - 默认false- 默默地忽略诸如解析错误和无效域之类的事情。 Store此选项不会忽略错误。
• sameSiteContext -字符串-默认未设置-设置'none'，'lax'或'strict'参见[SameSite饼干]以下。

根据 RFC，.hostOnly如果 cookie 字符串中没有“Domain=”参数（或.domain在 Cookie 对象上为空），则设置该属性。在这种情况下，该.domain属性设置为完全限定的主机名currentUrl。匹配这个 cookie 需要一个精确的主机名匹配（而不是domainMatch像往常一样）。

.setCookieSync(cookieOrString, currentUrl, [{options}])

的同步版本setCookie；仅适用于同步存储（例如 default MemoryCookieStore）。

.getCookies(currentUrl, [{options},] cb(err,cookies))

检索可以在当前 url 的 Cookie 标头中发送的 cookie 列表。

如果遇到一个错误，这是作为传递err给回调，否则Array的Cookie对象传递。cookieCompare()除非{sort:false}给出选项，否则数组将排序。

该options对象可以省略，并且可以具有以下属性：

• http - 布尔值 - 默认值true- 指示这是 HTTP 还是非 HTTP API。影响 HttpOnly cookie。
• 安全- 布尔值 - 从 url 自动检测 - 指示这是否是“安全”API。如果 currentUrl 以https:或开头，wss:则默认为true，否则为false。
• 现在- 日期 - 默认new Date()- 用于创建/访问 cookie 的时间
• expire - boolean - default true- 执行 cookie 的到期时间检查并从 Store 中异步删除过期的 cookie。使用false将返回过期的 cookie而不会将它们从存储中删除（这对于重放 Set-Cookie 标头很有用，可能）。
• allPaths - boolean - default false- if true，不要按路径对 cookie 进行范围。默认使用符合 RFC 的路径范围。注意：底层存储可能不支持（默认MemoryCookieStore支持）。
• sameSiteContext - 字符串 - 默认未设置 - 将此设置为'none'，'lax'或'strict'在检索时强制执行 SameSite cookie。请参阅下面的 [SameSite Cookie]。

.lastAccessed返回的 cookie的属性将被更新。

.getCookiesSync(currentUrl, [{options}])

的同步版本getCookies；仅适用于同步存储（例如 default MemoryCookieStore）。

.getCookieString(...)

接受相同的选项，.getCookies()但将适合 Cookie 标头的字符串而不是数组传递给回调。只需Cookie通过.cookieString().

.getCookieStringSync(...)

的同步版本getCookieString；仅适用于同步存储（例如 default MemoryCookieStore）。

.getSetCookieStrings(...)

返回适合Set-Cookie标头的字符串数组。接受与 相同的选项.getCookies()。简单地通过.toString().

.getSetCookieStringsSync(...)

的同步版本getSetCookieStrings；仅适用于同步存储（例如 default MemoryCookieStore）。

.serialize(cb(err,serializedObject))

如果底层存储支持.getAllCookies.

注意：自定义Cookie属性将被丢弃。如果要序列化属性，请将属性名称添加到Cookie.serializablePropertiesArray。

请参阅[序列化格式]。

.serializeSync()

.serialize 的同步版本

.toJSON()

.serializeSync() 的别名，以方便JSON.stringify(cookiejar).

CookieJar.deserialize(serialized, [store], cb(err,object))

创建一个新的 Jar 并将序列化的 Cookie 添加到底层存储中。每个Cookie都是store.putCookie按照它们在序列化中出现的顺序添加的。

该store参数是可选的，但应该是一个实例Store。默认情况下，MemoryCookieStore会创建一个新实例。

为方便起见，如果serialized是字符串，则JSON.parse先通过。如果抛出错误，则将其传递给回调。

CookieJar.deserializeSync(serialized, [store])

的同步版本.deserialize。 请注意，store必须同步才能使其工作。

CookieJar.fromJSON(string)

的别名.deserializeSync以提供与Cookie.fromJSON().

.clone([store,]cb(err,newJar))

生成此 jar 的深度克隆。对原作的修改不会影响克隆，反之亦然。

该store参数是可选的，但应该是一个实例Store。默认情况下，MemoryCookieStore会创建一个新实例。只要源实现.getAllCookies()和目标实现，就支持 Store 类型之间的传输.putCookie()。

.cloneSync([store])

的同步版本.clone，返回一个新CookieJar实例。

该store参数是可选的，但如果指定，则必须是同步 Store实例。如果未通过，MemoryCookieStore则使用的新实例。

的源和目的地必须都是同步Store秒。如果一个或两个存储是异步的，请.clone改用。回想一下，它MemoryCookieStore支持同步和异步 API 调用。

.removeAllCookies(cb(err))

从 jar 中删除所有 cookie。

这是tough-cookie2.5 版的新的向后兼容功能，因此并非所有 Store 都会有效地实现它。对于没有实现的 Stores，removeAllCookies回退是调用removeCookieafter getAllCookies。如果getAllCookies失败或未在 Store 中实现，则返回该错误。如果一个或多个removeCookie调用失败，则只返回第一个错误。

.removeAllCookiesSync()

同步版本 .removeAllCookies()

Store

CookieJar Store 的基类。可作为tough.Store。

Store API

每个CookieJar实例的存储模型都可以替换为自定义实现。默认是MemoryCookieStore可以在lib/memstore.js文件中找到的。API 使用 continuation-passing-style 来允许异步存储。

Stores 应该从基Store类继承，它可以作为require('tough-cookie').Store.

默认情况下存储是异步的，但如果store.synchronous设置为true，则可以使用*Sync包含的方法CookieJar（但是，继续传递样式

domain在调用之前，所有参数都将被规范化。

Cookie 存储必须具有以下所有方法。

store.findCookie(domain, path, key, cb(err,cookie))

检索具有给定域、路径和密钥（又名名称）的 cookie。RFC 坚持认为，这些 cookie 中的一个应该存在于 Store 中。如果 Store 使用版本控制，这意味着应该返回最新/最新的此类 cookie。

回调接受一个错误和结果Cookie对象。如果未找到 cookie，则null必须改为传递（即不是错误）。

store.findCookies(domain, path, cb(err,cookies))

定位与给定域和路径匹配的 cookie。这在cookiejar.getCookies()上面的上下文中最常被调用。

如果没有找到 cookie，回调必须传递一个空数组。

将根据 RFC（域匹配、路径匹配、http-only-flag、secure-flag、expiry 等）检查结果列表是否适用于当前请求，因此可以使用乐观搜索算法在实现这个方法的时候。但是，使用的搜索算法应该尝试查找domainMatch()域和pathMatch()路径的cookie，以限制需要完成的检查量。

从 0.9.12 版本开始，上述allPaths选项cookiejar.getCookies()将导致此处的路径为null. 如果路径是null，则不得执行路径匹配（即仅域匹配）。

store.putCookie(cookie, cb(err))

向 Store 添加一个新的 cookie。实现应该用相同的.domain、.path和.key属性替换任何现有的 cookie —— 根据实现的性质，在调用fetchCookie和putCookie重复之间putCookie可能会发生。

该cookie对象不能被修改; 调用者已经更新了.creation和.lastAccessed属性。

如果无法存储 cookie，则传递错误。

store.updateCookie(oldCookie, newCookie, cb(err))

更新现有的 cookie。实现必须.value使用相同的domain,.path和 来更新cookie 的.key。实现应该检查存储中的旧值是否等同于oldCookie- 如何解决冲突取决于存储。

该.lastAccessed属性将始终是两个对象（在精度通过JavaScript的时钟可能）之间的不同。两者.creation和.creationIndex保证相同。 Store 可以忽略或推迟.lastAccessed更改，代价是影响选择 cookie 进行自动删除的方式（例如，最近最少使用，这取决于 Store 来实施）。

Store 可能希望优化 Store 中.valuecookie 的更改与存储新 cookie。如果实现未定义此方法，则调用的存根putCookie(newCookie,cb)将添加到存储对象中。

在newCookie与oldCookie对象不得修改。

如果 newCookie 无法存储，则传递错误。

store.removeCookie(domain, path, key, cb(err))

从存储中删除 cookie（请参阅findCookie有关唯一性约束的注释）。

如果 cookie 不存在，则实现不得传递错误；仅传递由于无法删除现有 cookie 而导致的错误。

store.removeCookies(domain, path, cb(err))

从 Store 中删除匹配的 cookie。该path参数是可选的，如果丢失意味着应该删除域中的所有路径。

仅当删除任何现有 cookie 失败时才传递错误。

store.removeAllCookies(cb(err))

可选。从 Store 中删除所有 cookie。

如果无法删除一个或多个 cookie，则传递错误。

注意：tough-cookie2.5 版本的新方法，所以不是所有的 Store 都会实现这个，另外一些 Store 可能会选择不实现这个。

store.getAllCookies(cb(err, cookies))

可选。Array在 期间生成所有 cookie 中的一个jar.serialize()。数组中的项可以是真正的Cookie对象，也可以是Object具有 [Serialization Format] 数据结构的泛型。

Cookie 应该按创建顺序返回，以通过compareCookies(). 作为参考，MemoryCookieStore将排序，.creationIndex因为它在Cookie内部使用真正的对象。如果您不按创建顺序返回 cookie，它们仍会按创建时间排序，但这只有 1 毫秒的精度。请参阅compareCookies了解更多详情。

如果检索失败，则传递错误。

注意：由于技术限制，并非所有 Store 都可以实现此功能，因此它是可选的。

MemoryCookieStore

继承自Store.

默认情况下使用的仅内存 CookieJar 同步存储实现。尽管是同步实现，但它可用于CookieJarAPI的同步和异步形式。支持序列化getAllCookies、 和removeAllCookies。

Community Cookie Stores

这些是由社区创作和维护的一些 Store 实现。它们不是官方的，我们不保证它们，但您可能有兴趣看一看：

• db-cookie-store: SQL 包括基于 SQLite 的数据库
• file-cookie-store: 磁盘上的 Netscape cookie 文件格式
• redis-cookie-store: Redis
• tough-cookie-filestore: 磁盘上的 JSON
• tough-cookie-web-storage-store: DOM localStorage 和 sessionStorage

序列化格式

注意：如果要Cookie序列化自定义属性，请将属性名称添加到Cookie.serializableProperties.

{
    // The version of tough-cookie that serialized this jar.
    version: 'tough-cookie@1.x.y',

    // add the store type, to make humans happy:
    storeType: 'MemoryCookieStore',

    // CookieJar configuration:
    rejectPublicSuffixes: true,
    // ... future items go here

    // Gets filled from jar.store.getAllCookies():
    cookies: [
      {
        key: 'string',
        value: 'string',
        // ...
        /* other Cookie.serializableProperties go here */
      }
    ]
  }

RFC6265bis

正在开发对 RFC6265bis 修订版 02 的支持。由于这是对 RFC6252 的综合修订，因此支持分为功能领域。

不使用安全 Cookie

尚不支持。

此更改使得如果 cookie 从服务器发送到具有Secure属性的客户端，则通道也必须是安全的，否则 cookie 将被忽略。

同站点 Cookie

支持的。

此更改使服务器和支持客户端可以通过禁止SameSite跨域发送 cookie来减轻某些类型的 CSRF 攻击。

在 Cookie 对象本身上，您可以获取/设置.sameSite属性，该属性将被序列化为SameSite=cookie 属性。当未设置或时undefined，不会SameSite=序列化任何属性。此属性的有效值'none'，'lax'或'strict'。其他值将按原样序列化。

解析具有SameSitecookie 属性的cookie 时，将'lax'或以外的值'strict'解析为'none'. 例如，SomeCookie=SomeValue; SameSite=garbage将解析以便cookie.sameSite === 'none'.

为了支持SameSite饼干，你必须提供一个sameSiteContext选项，都 setCookie和getCookies。此选项的有效值与 Cookie 对象类似，但具有特殊含义：

1. 'strict' mode - 如果请求位于同一个“cookie 站点”（请参阅​​ RFC 草案了解这意味着什么），传递此选项以添加一层针对 CSRF 的防御。
2. 'lax'mode - 如果请求来自另一个站点，但直接由于用户导航，例如，<link type=prefetch>or <a href="...">， pass sameSiteContext: 'lax'。
3. 'none'- 否则，通过sameSiteContext: 'none'（这表示跨域请求）。
4. unset/ undefined- SameSite不会被强制执行！当 CSRF 不在正在构建的系统的威胁模型中时，这可能是一个有效的用例。

强烈建议您阅读 RFC 6265bis 以了解有关 SameSite cookie 的详细信息。特别是第 8.8 节讨论了安全考虑和纵深防御。

Cookie 前缀

支持的。

Cookie 前缀是一种通过检查 cookie 名称的前几个字符来指示给定 cookie 设置了一组属性的方法。

Cookie 前缀在6265bis 的第 4.1.3 节中定义。定义了两个前缀：

1. "__Secure-" Prefix：如果 cookie 的名称以字符串“__Secure-”的区分大小写匹配开头，则 cookie 将被设置为“安全”属性。
2. "__Host-" Prefix：如果 cookie 的名称以字符串“__Host-”的区分大小写匹配开头，则 cookie 将被设置为“安全”属性、值为“/”的“路径”属性，并且没有“域”属性。

如果prefixSecurity为 启用CookieJar，则不会添加与上面定义的前缀匹配但不遵守属性限制的 cookie。

您可以通过将prefixSecurity选项传递给来定义此功能CookieJar。它可以是 3 个值之一：

1. silent: 启用 cookie 前缀检查，但如果不满足条件，则静默无法添加 cookie。默认。
2. strict: 如果条件不满足，则启用 cookie 前缀检查和错误输出。
3. unsafe-disabled: 禁用 cookie 前缀检查。

请注意，如果ignoreError传入 astrue那么无论prefixSecurity选项如何（假设它已启用），错误都将保持沉默。

项目地址：https://github.com/salesforce/tough-cookie