RFC6265 Cookies e CookieJar para Node.js

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

# Instalação

É _tão_ fácil!

`npm install tough-cookie`

Por que esse nome? Os módulos NPM `cookie`, `cookies` e `cookiejar` já estavam ocupados.

## Suporte de Versão

O suporte para versões do node.js seguirá o do módulo [request](https://www.npmjs.com/package/request).

# API

## tough

Funções no módulo que você obtém de `require('tough-cookie')`. Todas podem ser usadas como funções puras e não precisam ser "ligadas".

**Nota**: antes da versão 1.0.x, várias dessas funções aceitavam um parâmetro `strict`. Isso foi removido da API desde então, pois não era mais necessário.

### `parseDate(string)`

Analisa uma string de data de cookie em um `Date`. A análise segue a RFC6265 Seção 5.1.1, não `Date.parse()`.

### `formatDate(date)`

Formata uma Data em uma string RFC1123 (o formato recomendado pela RFC6265).

### `canonicalDomain(str)`

Transforma um nome de domínio em um nome de domínio canônico. O nome de domínio canônico é um nome de domínio com espaços removidos, em minúsculas, sem ponto inicial e opcionalmente codificado em punycode (Seção 5.1.2 da RFC6265). Na maioria dos casos, esta função é idempotente (pode ser executada novamente em sua saída sem efeitos adversos).

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

Responde "este domínio real corresponde ao domínio em um cookie?". O `str` é o nome de domínio "atual" e o `domStr` é o nome de domínio do "cookie". A correspondência segue a RFC6265 Seção 5.1.3, mas ajuda pensar nisso como uma "correspondência de sufixo".

O parâmetro `canonicalize` executará os outros dois parâmetros através de `canonicalDomain` ou não.

### `defaultPath(path)`

Dado um caminho de solicitação/resposta atual, fornece o Caminho apropriado para armazenar em um cookie. Isso é basicamente o "diretório" de um "arquivo" no caminho, mas é especificado pela Seção 5.1.4 da RFC.

O parâmetro `path` DEVE ser _apenas_ a parte do nome do caminho de uma URI (ou seja, exclui o nome do host, consulta, fragmento, etc.). Esta é a propriedade `.pathname` da saída de `uri.parse()` do node.

### `pathMatch(reqPath,cookiePath)`

Responde "o caminho da solicitação corresponde a um determinado caminho de cookie?" conforme RFC6265 Seção 5.1.4. Retorna um booleano.

Isso é essencialmente uma correspondência de prefixo onde `cookiePath` é um prefixo de `reqPath`.

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

atalho para `Cookie.parse(cookieString[, options])`

### `fromJSON(string)`

atalho para `Cookie.fromJSON(string)`

### `getPublicSuffix(hostname)`

Retorna o sufixo público deste nome de host. O sufixo público é o nome de domínio mais curto no qual um cookie pode ser definido. Retorna `null` se o nome de host não puder ter cookies definidos para ele.

Por exemplo: `www.example.com` e `www.subdomain.example.com` ambos têm o sufixo público `example.com`.

Para mais informações, veja http://publicsuffix.org/. Este módulo obtém sua lista desse site. Esta chamada é atualmente um invólucro em torno do [método get()](https://www.npmjs.com/package/psl#pslgetdomain) do [`psl`](https://www.npmjs.com/package/psl).

### `cookieCompare(a,b)`

Para uso com `.sort()`, ordena uma lista de cookies na ordem recomendada dada pela RFC (Seção 5.4 passo 2). O algoritmo de ordenação é, em ordem de precedência:

* `.path` mais longo
* `.creation` mais antigo (que tem precisão de 1ms, igual a `Date`)
* menor `.creationIndex` (para superar a precisão de 1ms)``` javascript
var cookies = [ /* unsorted array of Cookie objects */ ];
cookies = cookies.sort(cookieCompare);

Nota: Como o Date do JavaScript tem precisão limitada a 1 ms, cookies dentro do mesmo milissegundo são totalmente possíveis. Isso é especialmente verdade ao usar a opção now em .setCookie(). A propriedade .creationIndex é um contador global por processo, atribuído durante a construção com new Cookie(). Isso preserva o espírito da ordenação RFC: cookies mais antigos vão primeiro. Isso funciona muito bem para MemoryCookieStore, já que os cabeçalhos Set-Cookie são analisados em ordem, mas talvez não seja tão bom para sistemas distribuídos. Stores sofisticados podem desejar definir isso como algum outro relógio lógico de modo que, se os cookies A e B forem criados no mesmo milissegundo, mas o cookie A for criado antes do cookie B, então A.creationIndex < B.creationIndex. Se você quiser alterar o contador global, o que provavelmente não deveria fazer, ele está armazenado em Cookie.cookiesCreated.

permuteDomain(domain)

Gera uma lista de todos os domínios possíveis que correspondem a domainMatch() no parâmetro. Pode ser útil para implementar armazenamentos de cookies.

permutePath(path)

Gera uma lista de todos os caminhos possíveis que correspondem a pathMatch() no parâmetro. Pode ser útil para implementar armazenamentos de cookies.

Cookie

Exportado via tough.Cookie.

Cookie.parse(cookieString[, options])

Analisa um único cabeçalho HTTP Cookie ou Set-Cookie em um objeto Cookie. Retorna undefined se a string não puder ser analisada.

O parâmetro options não é obrigatório e atualmente tem apenas uma propriedade:

• loose - booleano - se true ativa a análise de cookies sem chave como =abc e =, que não estão em conformidade com a RFC.

Se options não for um objeto, ele é ignorado, o que significa que você pode usar Array#map com ele.

Veja como processar o(s) cabeçalho(s) Set-Cookie em uma resposta HTTP/HTTPS do 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:_ na versão 2.3.3, tough-cookie limitou o número de espaços antes do `=` a 256 caracteres. Essa limitação foi removida desde então.
Veja [Issue 92](https://github.com/salesforce/tough-cookie/issues/92)

### Propriedades

Propriedades do objeto Cookie:

  * _key_ - string - o nome ou chave do cookie (padrão "")
  * _value_ - string - o valor do cookie (padrão "")
  * _expires_ - `Date` - se definido, o atributo `Expires=` do cookie (padrão é a string `"Infinity"`). Veja `setExpires()`
  * _maxAge_ - segundos - se definido, o atributo `Max-Age=` _em segundos_ do cookie. Também pode ser definido como as strings `"Infinity"` e `"-Infinity"` para não expiração e expiração imediata, respectivamente. Veja `setMaxAge()`
  * _domain_ - string - o atributo `Domain=` do cookie
  * _path_ - string - o `Path=` do cookie
  * _secure_ - boolean - a flag `Secure` do cookie
  * _httpOnly_ - boolean - a flag `HttpOnly` do cookie
  * _extensions_ - `Array` - quaisquer atributos de cookie não reconhecidos como strings (mesmo que contenham sinais de igual)
  * _creation_ - `Date` - quando este cookie foi construído
  * _creationIndex_ - number - definido na construção, usado para fornecer maior precisão de ordenação (veja `cookieCompare(a,b)` para uma explicação completa)

Após um cookie ter passado por `CookieJar.setCookie()`, ele terá os seguintes atributos adicionais:

  * _hostOnly_ - boolean - é um cookie somente de host (ou seja, nenhum campo Domain foi definido, mas foi implícito)
  * _pathIsDefault_ - boolean - se verdadeiro, não havia campo Path no cookie e `defaultPath()` foi usado para derivar um.
  * _creation_ - `Date` - **modificado** desde a construção até quando o cookie foi adicionado ao jar
  * _lastAccessed_ - `Date` - última vez que o cookie foi acessado. Afetará a limpeza de cookies quando implementada. Usar `cookiejar.getCookies(...)` atualizará este atributo.

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

Recebe um objeto de opções que pode conter qualquer uma das propriedades do Cookie acima, usando o padrão para propriedades não especificadas.

### `.toString()`

codifica para um valor de cabeçalho Set-Cookie. O campo de cookie Expires é definido usando `formatDate()`, mas é omitido inteiramente se `.expires` for `Infinity`.

### `.cookieString()`

codifica para um valor de cabeçalho Cookie (ou seja, as propriedades `.key` e `.value` unidas com '=').

### `.setExpires(String)`

define a expiração com base em uma string de data passada por `parseDate()`. Se parseDate retornar `null` (ou seja, não consegue analisar esta string de data), `.expires` é definido como `"Infinity"` (uma string).

### `.setMaxAge(number)`

define o maxAge em segundos. Converte `-Infinity` para `"-Infinity"` e `Infinity` para `"Infinity"` para que seja serializado corretamente em JSON.

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

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

expiryTime() calcula os milissegundos absolutos da época Unix em que este cookie expira. expiryDate() funciona de forma semelhante, exceto que retorna um objeto `Date`. Observe que em ambos os casos o parâmetro `now` deve estar em milissegundos.

Max-Age tem precedência sobre Expires (conforme a RFC). O atributo `.creation` -- ou, por padrão, o parâmetro `now` -- é usado para compensar o atributo `.maxAge`.

Se Expires (`.expires`) estiver definido, ele é retornado.

Caso contrário, `expiryTime()` retorna `Infinity` e `expiryDate()` retorna um objeto `Date` para "Tue, 19 Jan 2038 03:14:07 GMT" (a data mais recente que pode ser expressa por um `time_t` de 32 bits; o limite comum para a maioria dos agentes de usuário).

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

calcula o TTL relativo a `now` (milissegundos). As mesmas regras de precedência que para `expiryTime`/`expiryDate` se aplicam.

O "número" `Infinity` é retornado para cookies sem expiração explícita e `0` é retornado se o cookie estiver expirado. Caso contrário, é retornado um tempo de vida em milissegundos.

### `.canonicalizedDomain()`

### `.cdomain()`

retorna o campo `.domain` canônico. Este é convertido para minúsculas e codificado em punycode (RFC3490) se o domínio tiver algum caractere não ASCII.

### `.toJSON()`

Para conveniência ao usar `JSON.serialize(cookie)`. Retorna um `Object` simples que pode ser serializado em JSON.

Quaisquer propriedades `Date` (ou seja, `.expires`, `.creation` e `.lastAccessed`) são exportadas no formato ISO (`.toISOString()`).

**NOTA**: Propriedades `Cookie` personalizadas serão descartadas. No tough-cookie 1.x, como não havia um método `.toJSON` explicitamente definido, todas as propriedades enumeráveis eram capturadas. Se você quiser que uma propriedade seja serializada, adicione o nome da propriedade ao array `Cookie.serializableProperties`.

### `Cookie.fromJSON(strOrObj)`

Faz o inverso de `cookie.toJSON()`. Se receber uma string, fará `JSON.parse()` nela primeiro.

Quaisquer propriedades `Date` (ou seja, `.expires`, `.creation` e `.lastAccessed`) são analisadas via `Date.parse()`, não pelo tough-cookie `parseDate`, já que são timestamps JavaScript/JSON sendo tratados nesta camada.

Retorna `null` em caso de erro de análise JSON.

### `.clone()`

Faz uma clonagem profunda deste cookie, exatamente implementado como `Cookie.fromJSON(cookie.toJSON())`.

### `.validate()`

Status: *EM ANDAMENTO*. Funciona para algumas coisas, mas não é abrangente.

Valida os atributos do cookie quanto à correção semântica. Útil para verificação "lint" de qualquer cabeçalho Set-Cookie que você gerar. Por enquanto, retorna um booleano, mas eventualmente pode retornar uma string de motivo -- você pode preparar para o futuro com esta construção:``` javascript
if (cookie.validate() === true) {
  // it's tasty
} else {
  // yuck!
}

CookieJar

Exportado via tough.CookieJar.

CookieJar([store],[options])

Simplesmente use new CookieJar(). Se desejar usar um armazenamento personalizado, passe-o ao construtor, caso contrário um MemoryCookieStore será criado e utilizado.

O objeto options pode ser omitido e pode ter as seguintes propriedades:

• rejectPublicSuffixes - booleano - padrão true - rejeitar cookies com domínios como "com" e "co.uk"
• looseMode - booleano - padrão false - aceitar cookies malformados como bar e =bar, que têm um nome vazio implícito. Isto não está no padrão, mas é usado às vezes na web e é aceito pela maioria dos navegadores.

Como eventualmente este módulo gostaria de suportar CookieJars de base de dados/remoto/etc., o estilo de passagem de continuação é usado para os métodos CookieJar.

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

Tenta definir o cookie no jar de cookies. Se a operação falhar, um erro será passado para o callback cb, caso contrário o cookie é passado adiante. O cookie terá as propriedades .creation, .lastAccessed e .hostOnly atualizadas.

O objeto options pode ser omitido e pode ter as seguintes propriedades:

• http - booleano - padrão true - indica se esta é uma API HTTP ou não-HTTP. Afeta cookies HttpOnly.
• secure - booleano - autodetectar a partir da url - indica se esta é uma API "Segura". Se o currentUrl começar com https: ou wss:, então o padrão é true, caso contrário false.
• now - Date - padrão new Date() - o que usar para o tempo de criação/acesso dos cookies
• ignoreError - booleano - padrão false - ignorar silenciosamente coisas como erros de análise e domínios inválidos. Erros de Store não são ignorados por esta opção.

De acordo com a RFC, a propriedade .hostOnly é definida se não houver parâmetro "Domain=" na string do cookie (ou se .domain for nulo no objeto Cookie). A propriedade .domain é definida como o nome de host totalmente qualificado de currentUrl neste caso. Corresponder a este cookie requer uma correspondência exata de nome de host (não um domainMatch como de costume).

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

Versão síncrona de setCookie; funciona apenas com armazenamentos síncronos (por exemplo, o MemoryCookieStore padrão).

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

Recupera a lista de cookies que podem ser enviados no cabeçalho Cookie para a url atual.

Se um erro for encontrado, ele é passado como err para o callback, caso contrário um Array de objetos Cookie é passado. O array é ordenado com cookieCompare() a menos que a opção {sort:false} seja fornecida.

O objeto options pode ser omitido e pode ter as seguintes propriedades:

• http - booleano - padrão true - indica se esta é uma API HTTP ou não-HTTP. Afeta cookies HttpOnly.
• secure - booleano - autodetectar a partir da url - indica se esta é uma API "Segura". Se o currentUrl começar com https: ou wss:, então o padrão é true, caso contrário false.
• now - Date - padrão new Date() - o que usar para o tempo de criação/acesso dos cookies
• expire - booleano - padrão true - realizar verificação de tempo de expiração dos cookies e remover assincronamente cookies expirados do armazenamento. Usar false retornará cookies expirados e não os removerá do armazenamento (o que é útil para reproduzir cabeçalhos Set-Cookie, potencialmente).
• allPaths - booleano - padrão false - se true, não limitar cookies por caminho. O padrão usa escopo de caminho conforme RFC. Nota: pode não ser suportado pelo armazenamento subjacente (o MemoryCookieStore padrão suporta).

A propriedade .lastAccessed dos cookies retornados terá sido atualizada.

.getCookiesSync(currentUrl, [{options}])

Versão síncrona de getCookies; funciona apenas com armazenamentos síncronos (por exemplo, o MemoryCookieStore padrão).

.getCookieString(...)

Aceita as mesmas opções que .getCookies() mas passa uma string adequada para um cabeçalho Cookie em vez de um array para o callback. Simplesmente mapeia o array Cookie via .cookieString().

.getCookieStringSync(...)

Versão síncrona de getCookieString; funciona apenas com armazenamentos síncronos (por exemplo, o MemoryCookieStore padrão).

.getSetCookieStrings(...)

Retorna um array de strings adequadas para cabeçalhos Set-Cookie. Aceita as mesmas opções que .getCookies(). Simplesmente mapeia o array de cookies via .toString().

.getSetCookieStringsSync(...)

Versão síncrona de getSetCookieStrings; funciona apenas com armazenamentos síncronos (por exemplo, o MemoryCookieStore padrão).

.serialize(cb(err,serializedObject))

Serializa o Jar se o armazenamento subjacente suportar .getAllCookies.

NOTA: Propriedades personalizadas de Cookie serão descartadas. Se quiser que uma propriedade seja serializada, adicione o nome da propriedade ao Array Cookie.serializableProperties.

Veja [Formato de Serialização].

.serializeSync()

Versão síncrona de .serialize

.toJSON()

Alias de .serializeSync() para a conveniência de JSON.stringify(cookiejar).

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

Um novo Jar é criado e os Cookies serializados são adicionados ao armazenamento subjacente. Cada Cookie é adicionado via store.putCookie na ordem em que aparecem na serialização.

O argumento store é opcional, mas deve ser uma instância de Store. Por padrão, uma nova instância de MemoryCookieStore é criada.

Como conveniência, se serialized for uma string, ela é passada por JSON.parse primeiro. Se isso lançar um erro, ele é passado para o callback.

CookieJar.deserializeSync(serialized, [store])

Versão síncrona de .deserialize. Nota que o store deve ser síncrono para que isso funcione.

CookieJar.fromJSON(string)

Alias de .deserializeSync para fornecer consistência com Cookie.fromJSON().

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

Produz um clone profundo deste jar. Modificações no original não afetarão o clone, e vice-versa.

O argumento store é opcional, mas deve ser uma instância de Store. Por padrão, uma nova instância de MemoryCookieStore é criada. A transferência entre tipos de armazenamento é suportada desde que a origem implemente .getAllCookies() e o destino implemente .putCookie().

.cloneSync([store])

Versão síncrona de .clone, retornando uma nova instância de CookieJar.

O argumento store é opcional, mas deve ser uma instância síncrona de Store se especificado. Se não for passado, uma nova instância de MemoryCookieStore é usada.

A origem e o destino devem ser ambos Stores síncronos. Se um ou ambos os armazenamentos forem assíncronos, use .clone em vez disso. Lembre-se que MemoryCookieStore suporta chamadas de API síncronas e assíncronas.

.removeAllCookies(cb(err))

Remove todos os cookies do jar.

Esta é uma nova funcionalidade compatível com versões anteriores do tough-cookie versão 2.5, então nem todos os Stores a implementarão eficientemente. Para Stores que não implementam removeAllCookies, a alternativa é chamar removeCookie após getAllCookies. Se getAllCookies falhar ou não estiver implementado no Store, esse erro é retornado. Se uma ou mais chamadas de removeCookie falharem, apenas o primeiro erro é retornado.

.removeAllCookiesSync()

Versão síncrona de .removeAllCookies()

Store

Classe base para armazenamentos CookieJar. Disponível como tough.Store.

Store API

O modelo de armazenamento para cada instância de CookieJar pode ser substituído por uma implementação personalizada. O padrão é MemoryCookieStore que pode ser encontrado no arquivo lib/memstore.js. A API usa estilo de passagem de continuação para permitir armazenamentos assíncronos.

Os Stores devem herdar da classe base Store, que está disponível como require('tough-cookie').Store.

Os Stores são assíncronos por padrão, mas se store.synchronous for definido como true, então os métodos *Sync no CookieJar contido podem ser usados (no entanto, o estilo de passagem de continuação

Todos os parâmetros domain terão sido normalizados antes da chamada.

O armazenamento de cookies deve ter todos os seguintes métodos.

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

Recupera um cookie com o domínio, caminho e chave fornecidos (também conhecido como nome). A RFC afirma que exatamente um desses cookies deve existir em um armazenamento. Se o armazenamento estiver usando versionamento, isso significa que o cookie mais recente/novo deve ser retornado.

O callback recebe um erro e o objeto Cookie resultante. Se nenhum cookie for encontrado, então null DEVE ser passado em vez disso (ou seja, não um erro).

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

Localiza cookies que correspondem ao domínio e caminho fornecidos. Isso é mais frequentemente chamado no contexto de cookiejar.getCookies() acima.

Se nenhum cookie for encontrado, o callback DEVE receber um array vazio.

A lista resultante será verificada quanto à aplicabilidade à solicitação atual de acordo com a RFC (domain-match, path-match, http-only-flag, secure-flag, expiry, etc.), então está tudo bem usar um algoritmo de busca otimista ao implementar este método. No entanto, o algoritmo de busca usado DEVE tentar encontrar cookies que domainMatch() o domínio e pathMatch() o caminho para limitar a quantidade de verificação que precisa ser feita.

A partir da versão 0.9.12, a opção allPaths para cookiejar.getCookies() acima fará com que o caminho aqui seja null. Se o caminho for null, a correspondência de caminho NÃO DEVE ser realizada (ou seja, apenas correspondência de domínio).

store.putCookie(cookie, cb(err))

Adiciona um novo cookie ao armazenamento. A implementação DEVE substituir qualquer cookie existente com as mesmas propriedades .domain, .path e .key -- dependendo da natureza da implementação, é possível que entre a chamada a fetchCookie e putCookie um putCookie duplicado possa ocorrer.

O objeto cookie NÃO DEVE ser modificado; o chamador já terá atualizado as propriedades .creation e .lastAccessed.

Passe um erro se o cookie não puder ser armazenado.

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

Atualiza um cookie existente. A implementação DEVE atualizar o .value para um cookie com o mesmo domain, .path e .key. A implementação DEVE verificar se o valor antigo no armazenamento é equivalente a oldCookie - como o conflito é resolvido depende do armazenamento.

A propriedade .lastAccessed será sempre diferente entre os dois objetos (na precisão possível via relógio do JavaScript). Ambos .creation e .creationIndex são garantidos como iguais. Os Stores PODEM ignorar ou adiar a alteração de .lastAccessed ao custo de afetar como os cookies são selecionados para exclusão automática (por exemplo, menos recentemente usados, o que depende do store implementar).

Os Stores podem desejar otimizar a alteração do .value do cookie no armazenamento em vez de armazenar um novo cookie. Se a implementação não definir este método, um stub que chama putCookie(newCookie,cb) será adicionado ao objeto store.

Os objetos newCookie e oldCookie NÃO DEVEM ser modificados.

Passe um erro se o newCookie não puder ser armazenado.

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

Remove um cookie do armazenamento (veja notas sobre findCookie sobre a restrição de unicidade).

A implementação NÃO DEVE passar um erro se o cookie não existir; apenas passe um erro devido à falha ao remover um cookie existente.

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

Remove cookies correspondentes do armazenamento. O parâmetro path é opcional, e se ausente significa que todos os caminhos em um domínio devem ser removidos.

Passe um erro APENAS se a remoção de algum cookie existente falhar.

store.removeAllCookies(cb(err))

Opcional. Remove todos os cookies do armazenamento.

Passe um erro se um ou mais cookies não puderem ser removidos.

Nota: Novo método a partir do tough-cookie versão 2.5, então nem todos os Stores o implementarão, além disso alguns stores podem optar por não implementá-lo.

store.getAllCookies(cb(err, cookies))

Opcional. Produz um Array de todos os cookies durante jar.serialize(). Os itens no array podem ser objetos Cookie verdadeiros ou Objects genéricos com a estrutura de dados [Formato de Serialização].

Os cookies DEVEM ser retornados em ordem de criação para preservar a ordenação via compareCookies(). Para referência, MemoryCookieStore ordenará por .creationIndex já que usa objetos Cookie verdadeiros internamente. Se você não retornar os cookies em ordem de criação, eles ainda serão ordenados por tempo de criação, mas isso tem apenas precisão de 1ms. Veja compareCookies para mais detalhes.

Passe um erro se a recuperação falhar.

Nota: nem todos os Stores podem implementar isso devido a limitações técnicas, então é opcional.

MemoryCookieStore

Herda de Store.

Uma implementação de armazenamento síncrono CookieJar apenas em memória, usada por padrão. Apesar de ser uma implementação síncrona, é utilizável com ambas as formas síncrona e assíncrona da API CookieJar. Suporta serialização, getAllCookies e removeAllCookies.

Armazenamentos de Cookie da Comunidade

Estas são algumas implementações de Store criadas e mantidas pela comunidade. Elas não são oficiais e não as endossamos, mas você pode ter interesse em dar uma olhada:

• db-cookie-store: SQL incluindo bases de dados baseadas em SQLite
• file-cookie-store: Formato de arquivo de cookie Netscape em disco
• redis-cookie-store: Redis
• tough-cookie-filestore: JSON em disco
• tough-cookie-web-storage-store: DOM localStorage e sessionStorage

Formato de Serialização

NOTA: se quiser ter propriedades personalizadas de Cookie serializadas, adicione o nome da propriedade 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 */
  }
]

}

# Direitos Autorais e Licença

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.