RFC6265 Cookies y CookieJar para Node.js

Sinopsis``` javascript

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('; '); });

# Instalación

¡Es _tan_ fácil!

`npm install tough-cookie`

¿Por qué ese nombre?  Los módulos de NPM `cookie`, `cookies` y `cookiejar` ya estaban ocupados.

## Soporte de versiones

El soporte para versiones de node.js seguirá el del módulo [request](https://www.npmjs.com/package/request).

# API

## tough

Funciones en el módulo que obtienes de `require('tough-cookie')`.  Todas pueden usarse como funciones puras y no necesitan estar "vinculadas".

**Nota**: antes de 1.0.x, varias de estas funciones aceptaban un parámetro `strict`. Esto se eliminó de la API desde entonces, ya que no era necesario.

### `parseDate(string)`

Analiza una cadena de fecha de cookie en un `Date`.  El análisis se realiza según la RFC6265 Sección 5.1.1, no `Date.parse()`.

### `formatDate(date)`

Da formato a un Date como una cadena RFC1123 (el formato recomendado por RFC6265).

### `canonicalDomain(str)`

Transforma un nombre de dominio en un nombre de dominio canónico.  El nombre de dominio canónico es un nombre de dominio recortado, en minúsculas, sin el punto inicial y, opcionalmente, codificado en punycode (Sección 5.1.2 de RFC6265).  En su mayor parte, esta función es idempotente (puede ejecutarse nuevamente sobre su salida sin efectos adversos).

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

Responde "¿coincide este dominio real con el dominio en una cookie?".  `str` es el nombre de dominio "actual" y `domStr` es el nombre de dominio de la "cookie".  La coincidencia se determina según la RFC6265 Sección 5.1.3, pero ayuda pensar en ello como una "coincidencia por sufijo".

El parámetro `canonicalize` hará pasar los otros dos parámetros por `canonicalDomain` o no.

### `defaultPath(path)`

Dado un path de solicitud/respuesta actual, da el Path apropiado para almacenar en una cookie.  Esto es básicamente el "directorio" de un "archivo" en el path, pero está especificado por la Sección 5.1.4 de la RFC.

El parámetro `path` DEBE ser _solo_ la parte de nombre de ruta de una URI (es decir, excluye el hostname, la consulta, el fragmento, etc.).  Esta es la propiedad `.pathname` de la salida de `uri.parse()` de node.

### `pathMatch(reqPath,cookiePath)`

Responde "¿coincide el request-path con un cookie-path dado?" según la RFC6265 Sección 5.1.4.  Devuelve un booleano.

Esto es esencialmente una coincidencia de prefijo donde `cookiePath` es un prefijo de `reqPath`.

### `parse(cookieString[, options])`

alias de `Cookie.parse(cookieString[, options])`

### `fromJSON(string)`

alias de `Cookie.fromJSON(string)`

### `getPublicSuffix(hostname)`

Devuelve el sufijo público de este hostname.  El sufijo público es el nombre de dominio más corto en el que se puede establecer una cookie.  Devuelve `null` si el hostname no puede tener cookies establecidas.

Por ejemplo: `www.example.com` y `www.subdomain.example.com` ambos tienen el sufijo público `example.com`.

Para más información, consulta http://publicsuffix.org/.  Este módulo deriva su lista de ese sitio.  Esta llamada es actualmente un envoltorio alrededor del [método get()](https://www.npmjs.com/package/psl#pslgetdomain) de [`psl`](https://www.npmjs.com/package/psl).

### `cookieCompare(a,b)`

Para usar con `.sort()`, ordena una lista de cookies en el orden recomendado por la RFC (Sección 5.4, paso 2).  El algoritmo de ordenamiento es, en orden de precedencia:

* `.path` más largo
* `.creation` más antiguo (que tiene una precisión de 1ms, igual que `Date`)
* `.creationIndex` más bajo (para superar la precisión de 1ms)``` javascript
var cookies = [ /* unsorted array of Cookie objects */ ];
cookies = cookies.sort(cookieCompare);

Nota: Dado que Date de JavaScript está limitado a una precisión de 1 ms, es totalmente posible que haya cookies dentro del mismo milisegundo. Esto es especialmente cierto cuando se usa la opción now con .setCookie(). La propiedad .creationIndex es un contador global por proceso, asignado durante la construcción con new Cookie(). Esto preserva el espíritu del ordenamiento RFC: las cookies más antiguas van primero. Esto funciona muy bien para MemoryCookieStore, ya que las cabeceras Set-Cookie se analizan en orden, pero puede no ser tan bueno para sistemas distribuidos. Los Stores sofisticados pueden querer establecer esto en algún otro reloj lógico de modo que si las cookies A y B se crean en el mismo milisegundo, pero la cookie A se crea antes que la cookie B, entonces A.creationIndex < B.creationIndex. Si quieres alterar el contador global, lo cual probablemente no deberías hacer, se almacena en Cookie.cookiesCreated.

permuteDomain(domain)

Genera una lista de todos los dominios posibles que domainMatch() el parámetro. Puede resultar útil para implementar almacenes de cookies.

permutePath(path)

Genera una lista de todas las rutas posibles que pathMatch() el parámetro. Puede resultar útil para implementar almacenes de cookies.

Cookie

Exportado mediante tough.Cookie.

Cookie.parse(cookieString[, options])

Analiza una única cabecera HTTP Cookie o Set-Cookie en un objeto Cookie. Devuelve undefined si la cadena no se puede analizar.

El parámetro options no es obligatorio y actualmente solo tiene una propiedad:

• loose - booleano - si es true, habilita el análisis de cookies sin clave como =abc y =, que no cumplen con RFC.

Si options no es un objeto, se ignora, lo que significa que puedes usar Array#map con él.

Así es como se procesan las cabeceras Set-Cookie en una respuesta HTTP/HTTPS de node:``` javascript if (res.headers['set-cookie'] instanceof Array) cookies = res.headers['set-cookie'].map(Cookie.parse); else cookies = [Cookie.parse(res.headers['set-cookie'])];

_Nota:_ en la versión 2.3.3, tough-cookie limitaba el número de espacios antes del `=` a 256 caracteres. Esta limitación se ha eliminado desde entonces.
Ver [Issue 92](https://github.com/salesforce/tough-cookie/issues/92)

### Propiedades

Propiedades del objeto Cookie:

  * _key_ - string - el nombre o clave de la cookie (por defecto "")
  * _value_ - string - el valor de la cookie (por defecto "")
  * _expires_ - `Date` - si se establece, el atributo `Expires=` de la cookie (por defecto la cadena `"Infinity"`). Ver `setExpires()`
  * _maxAge_ - segundos - si se establece, el atributo `Max-Age=` _en segundos_ de la cookie. También puede establecerse como las cadenas `"Infinity"` y `"-Infinity"` para no expiración y expiración inmediata, respectivamente. Ver `setMaxAge()`
  * _domain_ - string - el atributo `Domain=` de la cookie
  * _path_ - string - el `Path=` de la cookie
  * _secure_ - boolean - el indicador `Secure` de la cookie
  * _httpOnly_ - boolean - el indicador `HttpOnly` de la cookie
  * _extensions_ - `Array` - cualquier atributo de cookie no reconocido como cadenas (incluso si contienen signos igual)
  * _creation_ - `Date` - cuándo se construyó esta cookie
  * _creationIndex_ - number - se establece en la construcción, se usa para proporcionar mayor precisión de ordenación (consulte `cookieCompare(a,b)` para una explicación completa)

Después de que una cookie haya pasado por `CookieJar.setCookie()`, tendrá los siguientes atributos adicionales:

  * _hostOnly_ - boolean - si es una cookie de solo host (es decir, no se estableció un campo Domain, sino que se implicó)
  * _pathIsDefault_ - boolean - si es true, no había un campo Path en la cookie y se usó `defaultPath()` para derivar uno.
  * _creation_ - `Date` - **modificado** de la construcción al momento en que la cookie se añadió al jar
  * _lastAccessed_ - `Date` - última vez que se accedió a la cookie. Afectará a la limpieza de cookies cuando se implemente. El uso de `cookiejar.getCookies(...)` actualizará este atributo.

### `Cookie([{properties}])`

Recibe un objeto de opciones que puede contener cualquiera de las propiedades Cookie anteriores, y usa el valor predeterminado para las propiedades no especificadas.

### `.toString()`

Codifica a un valor de cabecera Set-Cookie. El campo de cookie Expires se establece usando `formatDate()`, pero se omite por completo si `.expires` es `Infinity`.

### `.cookieString()`

Codifica a un valor de cabecera Cookie (es decir, las propiedades `.key` y `.value` unidas con '=').

### `.setExpires(String)`

Establece la expiración según una cadena de fecha pasada a través de `parseDate()`. Si parseDate devuelve `null` (es decir, no puede analizar esta cadena de fecha), `.expires` se establece a `"Infinity"` (una cadena).

### `.setMaxAge(number)`

Establece el maxAge en segundos. Convierte `-Infinity` a `"-Infinity"` e `Infinity` a `"Infinity"` para que se serialice correctamente en JSON.

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

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

`expiryTime()` calcula los milisegundos absolutos de la época Unix en los que esta cookie expira. `expiryDate()` funciona de manera similar, excepto que devuelve un objeto `Date`. Tenga en cuenta que en ambos casos el parámetro `now` debe estar en milisegundos.

Max-Age tiene prioridad sobre Expires (según el RFC). El atributo `.creation` -- o, por defecto, el parámetro `now` -- se usa para compensar el atributo `.maxAge`.

Si Expires (`.expires`) está establecido, se devuelve eso.

De lo contrario, `expiryTime()` devuelve `Infinity` y `expiryDate()` devuelve un objeto `Date` para "Tue, 19 Jan 2038 03:14:07 GMT" (la fecha más reciente que puede expresarse con un `time_t` de 32 bits; el límite común para la mayoría de los agentes de usuario).

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

Calcula el TTL relativo a `now` (milisegundos). Se aplican las mismas reglas de precedencia que para `expiryTime`/`expiryDate`.

Se devuelve el "número" `Infinity` para cookies sin una expiración explícita y `0` si la cookie está expirada. De lo contrario, se devuelve un tiempo de vida en milisegundos.

### `.canonicalizedDomain()`

### `.cdomain()`

Devuelve el campo `.domain` canonizado. Se convierte a minúsculas y se codifica con punycode (RFC3490) si el dominio tiene caracteres no ASCII.

### `.toJSON()`

Para mayor comodidad al usar `JSON.serialize(cookie)`. Devuelve un `Object` simple que puede serializarse como JSON.

Cualquier propiedad `Date` (es decir, `.expires`, `.creation` y `.lastAccessed`) se exporta en formato ISO (`.toISOString()`).

**NOTA**: Las propiedades `Cookie` personalizadas se descartarán. En tough-cookie 1.x, como no había un método `.toJSON` definido explícitamente, se capturaban todas las propiedades enumerables. Si desea que una propiedad se serialice, agregue el nombre de la propiedad al array `Cookie.serializableProperties`.

### `Cookie.fromJSON(strOrObj)`

Hace lo inverso de `cookie.toJSON()`. Si se le pasa una cadena, primero hará `JSON.parse()` sobre ella.

Cualquier propiedad `Date` (es decir, `.expires`, `.creation` y `.lastAccessed`) se analiza mediante `Date.parse()`, no mediante `parseDate` de tough-cookie, ya que en esta capa se manejan marcas de tiempo de tipo JavaScript/JSON.

Devuelve `null` ante un error de análisis JSON.

### `.clone()`

Realiza una clonación profunda de esta cookie, implementada exactamente como `Cookie.fromJSON(cookie.toJSON())`.

### `.validate()`

Estado: *EN PROGRESO*. Funciona para algunas cosas, pero de ninguna manera es exhaustivo.

Valida los atributos de la cookie para verificar su corrección semántica. Útil para comprobar (lint) cualquier cabecera Set-Cookie que genere. Por ahora, devuelve un booleano, pero eventualmente podría devolver una cadena de motivo; puede prepararse para el futuro con esta construcción:``` javascript
if (cookie.validate() === true) {
  // it's tasty
} else {
  // yuck!
}

CookieJar

Exportado a través de tough.CookieJar.

CookieJar([store],[options])

Simplemente use new CookieJar(). Si desea utilizar un almacén (store) personalizado, páselo al constructor; de lo contrario, se creará y utilizará un MemoryCookieStore.

El objeto options puede omitirse y puede tener las siguientes propiedades:

• rejectPublicSuffixes - booleano - por defecto true - rechaza cookies con dominios como "com" y "co.uk"
• looseMode - booleano - por defecto false - acepta cookies malformadas como bar y =bar, que tienen un nombre vacío implícito. Esto no está en el estándar, pero se usa a veces en la web y es aceptado por (la mayoría de) los navegadores.

Dado que eventualmente este módulo querría soportar CookieJars de base de datos/remotos/etc., se usa el estilo de paso de continuación para los métodos de CookieJar.

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

Intenta establecer la cookie en el cookie jar. Si la operación falla, se pasará un error a la llamada de retorno cb; de lo contrario, la cookie se transmitirá. La cookie tendrá actualizadas las propiedades .creation, .lastAccessed y .hostOnly.

El objeto options puede omitirse y puede tener las siguientes propiedades:

• http - booleano - por defecto true - indica si esta es una API HTTP o no HTTP. Afecta a las cookies HttpOnly.
• secure - booleano - autodetectado desde la url - indica si esta es una API "Secure". Si el currentUrl comienza con https: o wss:, entonces el valor predeterminado es true, de lo contrario false.
• now - Date - por defecto new Date() - qué usar para el momento de creación/acceso de las cookies
• ignoreError - booleano - por defecto false - ignora silenciosamente cosas como errores de análisis y dominios inválidos. Los errores de Store no se ignoran con esta opción.

Según el RFC, la propiedad .hostOnly se establece si no había un parámetro "Domain=" en la cadena de la cookie (o .domain era null en el objeto Cookie). En este caso, la propiedad .domain se establece al nombre de host totalmente cualificado de currentUrl. Para que esta cookie coincida, se requiere una coincidencia exacta del nombre de host (no un domainMatch como es habitual).

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

Versión síncrona de setCookie; solo funciona con almacenes síncronos (p. ej., el MemoryCookieStore predeterminado).

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

Recupera la lista de cookies que se pueden enviar en un encabezado Cookie para la url actual.

Si se encuentra un error, se pasa como err a la llamada de retorno; de lo contrario, se pasa un Array de objetos Cookie. La matriz se ordena con cookieCompare() a menos que se proporcione la opción {sort:false}.

El objeto options puede omitirse y puede tener las siguientes propiedades:

• http - booleano - por defecto true - indica si esta es una API HTTP o no HTTP. Afecta a las cookies HttpOnly.
• secure - booleano - autodetectado desde la url - indica si esta es una API "Secure". Si el currentUrl comienza con https: o wss:, entonces el valor predeterminado es true, de lo contrario false.
• now - Date - por defecto new Date() - qué usar para el momento de creación/acceso de las cookies
• expire - booleano - por defecto true - realiza la comprobación del tiempo de expiración de las cookies y elimina asincrónicamente las cookies expiradas del almacén. Usar false devolverá cookies expiradas y no las eliminará del almacén (lo cual es útil potencialmente para reproducir encabezados Set-Cookie).
• allPaths - booleano - por defecto false - si es true, no limita las cookies por ruta. El valor predeterminado usa el ámbito de ruta conforme al RFC. Nota: puede que el almacén subyacente no lo soporte (el MemoryCookieStore predeterminado lo soporta).

La propiedad .lastAccessed de las cookies devueltas se habrá actualizado.

.getCookiesSync(currentUrl, [{options}])

Versión síncrona de getCookies; solo funciona con almacenes síncronos (p. ej., el MemoryCookieStore predeterminado).

.getCookieString(...)

Acepta las mismas opciones que .getCookies() pero pasa una cadena adecuada para un encabezado Cookie en lugar de un array a la llamada de retorno. Simplemente mapea el array de Cookie mediante .cookieString().

.getCookieStringSync(...)

Versión síncrona de getCookieString; solo funciona con almacenes síncronos (p. ej., el MemoryCookieStore predeterminado).

.getSetCookieStrings(...)

Devuelve un array de cadenas adecuadas para encabezados Set-Cookie. Acepta las mismas opciones que .getCookies(). Simplemente mapea el array de cookies mediante .toString().

.getSetCookieStringsSync(...)

Versión síncrona de getSetCookieStrings; solo funciona con almacenes síncronos (p. ej., el MemoryCookieStore predeterminado).

.serialize(cb(err,serializedObject))

Serializa el Jar si el almacén subyacente soporta .getAllCookies.

NOTA: Las propiedades personalizadas de Cookie se descartarán. Si desea que una propiedad sea serializada, agregue el nombre de la propiedad al array Cookie.serializableProperties.

Consulte [Formato de serialización].

.serializeSync()

Versión síncrona de .serialize

.toJSON()

Alias de .serializeSync() para conveniencia de JSON.stringify(cookiejar).

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

Se crea un nuevo Jar y las Cookies serializadas se agregan al almacén subyacente. Cada Cookie se agrega mediante store.putCookie en el orden en que aparecen en la serialización.

El argumento store es opcional, pero debe ser una instancia de Store. Por defecto, se crea una nueva instancia de MemoryCookieStore.

Como conveniencia, si serialized es una cadena, primero se pasa por JSON.parse. Si eso lanza un error, se pasa a la llamada de retorno.

CookieJar.deserializeSync(serialized, [store])

Versión síncrona de .deserialize. Nota: el store debe ser síncrono para que esto funcione.

CookieJar.fromJSON(string)

Alias de .deserializeSync para proporcionar consistencia con Cookie.fromJSON().

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

Produce un clon profundo de este jar. Las modificaciones al original no afectarán al clon, y viceversa.

El argumento store es opcional, pero debe ser una instancia de Store. Por defecto, se crea una nueva instancia de MemoryCookieStore. Se admite la transferencia entre tipos de almacén siempre que el origen implemente .getAllCookies() y el destino implemente .putCookie().

.cloneSync([store])

Versión síncrona de .clone, que devuelve una nueva instancia de CookieJar.

El argumento store es opcional, pero si se especifica, debe ser una instancia de Store síncrona. Si no se pasa, se usa una nueva instancia de MemoryCookieStore.

Tanto el origen como el destino deben ser Stores síncronos. Si uno o ambos almacenes son asíncronos, use .clone en su lugar. Recuerde que MemoryCookieStore soporta tanto llamadas de API síncronas como asíncronas.

.removeAllCookies(cb(err))

Elimina todas las cookies del jar.

Esta es una nueva característica retrocompatible de tough-cookie versión 2.5, por lo que no todos los Stores la implementarán de manera eficiente. Para Stores que no implementan removeAllCookies, la alternativa es llamar a removeCookie después de getAllCookies. Si getAllCookies falla o no está implementado en el Store, se devuelve ese error. Si una o más llamadas a removeCookie fallan, solo se devuelve el primer error.

.removeAllCookiesSync()

Versión síncrona de .removeAllCookies()

Store

Clase base para los almacenes de CookieJar. Disponible como tough.Store.

API de Store

El modelo de almacenamiento de cada instancia de CookieJar puede reemplazarse con una implementación personalizada. El predeterminado es MemoryCookieStore, que se puede encontrar en el archivo lib/memstore.js. La API usa el estilo de paso de continuación para permitir almacenes asíncronos.

Los Stores deberían heredar de la clase base Store, que está disponible como require('tough-cookie').Store.

Los Stores son asíncronos por defecto, pero si store.synchronous se establece en true, entonces los métodos *Sync en el del CookieJar contenedor se pueden usar (sin embargo, el estilo de paso de continuación

Todos los parámetros domain se habrán normalizado antes de la llamada.

El almacén de cookies debe tener todos los siguientes métodos.

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

Recupera una cookie con el dominio, la ruta y la clave (también conocida como nombre) dados. El RFC sostiene que exactamente una de estas cookies debería existir en un almacén. Si el almacén usa versionado, esto significa que se debe devolver la cookie más reciente/nueva.

La llamada de retorno recibe un error y el objeto Cookie resultante. Si no se encuentra ninguna cookie, se DEBE pasar null en su lugar (es decir, no un error).

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

Localiza cookies que coincidan con el dominio y la ruta dados. Esto se llama con mayor frecuencia en el contexto de cookiejar.getCookies() anterior.

Si no se encuentran cookies, se DEBE pasar un array vacío a la llamada de retorno.

La lista resultante se comprobará para ver si es aplicable a la solicitud actual según el RFC (coincidencia de dominio, coincidencia de ruta, indicador http-only, indicador secure, expiración, etc.), por lo que está bien usar un algoritmo de búsqueda optimista al implementar este método. Sin embargo, el algoritmo de búsqueda utilizado DEBERÍA intentar encontrar cookies que hagan domainMatch() con el dominio y pathMatch() con la ruta para limitar la cantidad de comprobaciones que deben realizarse.

A partir de la versión 0.9.12, la opción allPaths de cookiejar.getCookies() anterior hará que la ruta aquí sea null. Si la ruta es null, NO SE DEBE realizar la coincidencia de ruta (es decir, solo coincidencia de dominio).

store.putCookie(cookie, cb(err))

Agrega una nueva cookie al almacén. La implementación DEBERÍA reemplazar cualquier cookie existente con las mismas propiedades .domain, .path y .key; dependiendo de la naturaleza de la implementación, es posible que entre la llamada a fetchCookie y putCookie ocurra un putCookie duplicado.

El objeto cookie NO DEBE modificarse; quien llama ya habrá actualizado las propiedades .creation y .lastAccessed.

Pase un error si la cookie no puede almacenarse.

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

Actualiza una cookie existente. La implementación DEBE actualizar el .value de una cookie con el mismo domain, .path y .key. La implementación DEBERÍA comprobar que el valor antiguo en el almacén es equivalente a oldCookie; cómo se resuelve el conflicto depende del almacén.

La propiedad .lastAccessed siempre será diferente entre los dos objetos (con la precisión posible mediante el reloj de JavaScript). Tanto .creation como .creationIndex se garantiza que sean iguales. Los Stores PUEDEN ignorar o diferir el cambio de .lastAccessed al costo de afectar cómo se seleccionan las cookies para la eliminación automática (por ejemplo, menos usadas recientemente, lo cual depende del almacén implementarlo).

Los Stores pueden querer optimizar el cambio del .value de la cookie en el almacén en lugar de almacenar una cookie nueva. Si la implementación no define este método, se agregará al objeto del almacén un stub que llama a putCookie(newCookie,cb).

Los objetos newCookie y oldCookie NO DEBEN modificarse.

Pase un error si el newCookie no puede almacenarse.

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

Elimina una cookie del almacén (consulte las notas sobre findCookie acerca de la restricción de unicidad).

La implementación NO DEBE pasar un error si la cookie no existe; solo pase un error debido a la falla al eliminar una cookie existente.

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

Elimina las cookies que coinciden del almacén. El parámetro path es opcional y, si falta, significa que deben eliminarse todas las rutas en un dominio.

Pase un error SOLO si falló la eliminación de alguna cookie existente.

store.removeAllCookies(cb(err))

Opcional. Elimina todas las cookies del almacén.

Pase un error si una o más cookies no pueden eliminarse.

Nota: Método nuevo a partir de la versión 2.5 de tough-cookie, por lo que no todos los Stores lo implementarán; además, algunos almacenes pueden optar por no implementarlo.

store.getAllCookies(cb(err, cookies))

Opcional. Produce un Array de todas las cookies durante jar.serialize(). Los elementos del array pueden ser objetos Cookie reales u objetos Object genéricos con la estructura de datos [Formato de serialización].

Las cookies DEBERÍAN devolverse en orden de creación para preservar la ordenación mediante compareCookies(). Como referencia, MemoryCookieStore ordenará por .creationIndex ya que internamente usa objetos Cookie reales. Si no devuelve las cookies en orden de creación, igual se ordenarán por tiempo de creación, pero esto solo tiene una precisión de 1 ms. Consulte compareCookies para más detalle.

Pase un error si falla la recuperación.

Nota: no todos los Stores pueden implementar esto debido a limitaciones técnicas, por lo que es opcional.

MemoryCookieStore

Hereda de Store.

Una implementación de almacén síncrono CookieJar solo en memoria, utilizada por defecto. A pesar de ser una implementación síncrona, es utilizable con las formas tanto síncronas como asíncronas de la API CookieJar. Soporta serialización, getAllCookies y removeAllCookies.

Tiendas de cookies de la comunidad

Estas son algunas implementaciones de Store creadas y mantenidas por la comunidad. No son oficiales y no respondemos por ellas, pero puede que le interese echarles un vistazo:

• db-cookie-store: SQL, incluidas bases de datos basadas en SQLite
• file-cookie-store: formato de archivo de cookies Netscape en disco
• redis-cookie-store: Redis
• tough-cookie-filestore: JSON en disco
• tough-cookie-web-storage-store: DOM localStorage y sessionStorage

Formato de serialización

NOTA: si desea que las propiedades personalizadas de Cookie sean serializadas, agregue el nombre de la propiedad a Cookie.serializableProperties.```js { // The version of tough-cookie that serialized this jar. version: '[email protected]',

// 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 */
  }
]

}

# Derechos de autor y licencia

BSD-3-Clause:```text
 Copyright (c) 2015, Salesforce.com, Inc.
 All rights reserved.

 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions are met:

 1. Redistributions of source code must retain the above copyright notice,
 this list of conditions and the following disclaimer.

 2. Redistributions in binary form must reproduce the above copyright notice,
 this list of conditions and the following disclaimer in the documentation
 and/or other materials provided with the distribution.

 3. Neither the name of Salesforce.com nor the names of its contributors may
 be used to endorse or promote products derived from this software without
 specific prior written permission.

 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
 LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 POSSIBILITY OF SUCH DAMAGE.