guy2610/tough-cookie-patch-cve-2023-26136Bibliothèque d'analyse de cookies conforme à RFC6265 et de gestion CookieJar pour Node.js, avec correctif de sécurité CVE-2023-26136. Prend en charge la création, la validation, le stockage et la récupération de cookies pour les clients HTTP.
RFC6265 Cookies et CookieJar pour Node.js
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('; '); });
# Installation
C'est _si_ facile !
`npm install tough-cookie`
Pourquoi ce nom ? Les modules NPM `cookie`, `cookies` et `cookiejar` étaient déjà pris.
## Prise en charge des versions
La prise en charge des versions de node.js suivra celle du module [request](https://www.npmjs.com/package/request).
# API
## tough
Fonctions du module que vous obtenez à partir de `require('tough-cookie')`. Toutes peuvent être utilisées comme des fonctions pures et n'ont pas besoin d'être « liées ».
**Remarque** : avant 1.0.x, plusieurs de ces fonctions acceptaient un paramètre `strict`. Celui-ci a depuis été retiré de l'API car il n'était plus nécessaire.
### `parseDate(string)`
Analyse une chaîne de date de cookie en un objet `Date`. Analyse selon la Section 5.1.1 de la RFC6265, et non `Date.parse()`.
### `formatDate(date)`
Formate un objet Date en une chaîne RFC1123 (le format recommandé par la RFC6265).
### `canonicalDomain(str)`
Transforme un nom de domaine en un nom de domaine canonique. Le nom de domaine canonique est un nom de domaine dont les espaces de début et de fin sont supprimés, mis en minuscules, sans point initial et éventuellement encodé en punycode (Section 5.1.2 de la RFC6265). Dans l'ensemble, cette fonction est idempotente (elle peut être exécutée à nouveau sur sa sortie sans effets néfastes).
### `domainMatch(str,domStr[,canonicalize=true])`
Répond à la question « ce vrai domaine correspond-il au domaine dans un cookie ? ». `str` est le nom de domaine « courant » et `domStr` est le nom de domaine « cookie ». La correspondance est effectuée selon la Section 5.1.3 de la RFC6265, mais il est utile de la considérer comme une « correspondance par suffixe ».
Le paramètre `canonicalize` soumet les deux autres paramètres à `canonicalDomain` ou non.
### `defaultPath(path)`
Étant donné un chemin de requête/réponse actuel, renvoie le chemin approprié pour le stockage dans un cookie. C'est essentiellement le « répertoire » d'un « fichier » dans le chemin, mais spécifié par la Section 5.1.4 de la RFC.
Le paramètre `path` DOIT être _uniquement_ la partie chemin d'une URI (c'est-à-dire qu'il exclut le nom d'hôte, la requête, le fragment, etc.). C'est la propriété `.pathname` de la sortie de `uri.parse()` de node.
### `pathMatch(reqPath,cookiePath)`
Répond à la question « le chemin de requête correspond-il à un chemin de cookie donné ? » conformément à la Section 5.1.4 de la RFC6265. Renvoie un booléen.
C'est essentiellement une correspondance par préfixe où `cookiePath` est un préfixe de `reqPath`.
### `parse(cookieString[, options])`
alias de `Cookie.parse(cookieString[, options])`
### `fromJSON(string)`
alias de `Cookie.fromJSON(string)`
### `getPublicSuffix(hostname)`
Renvoie le suffixe public de ce nom d'hôte. Le suffixe public est le nom de domaine le plus court sur lequel un cookie peut être défini. Renvoie `null` si le nom d'hôte ne peut pas avoir de cookies définis pour lui.
Par exemple : `www.example.com` et `www.subdomain.example.com` ont tous deux pour suffixe public `example.com`.
Pour plus d'informations, voir http://publicsuffix.org/. Ce module tire sa liste de ce site. Cet appel est actuellement un wrapper autour de la [méthode get()](https://www.npmjs.com/package/psl#pslgetdomain) de [`psl`](https://www.npmjs.com/package/psl).
### `cookieCompare(a,b)`
Pour une utilisation avec `.sort()`, trie une liste de cookies dans l'ordre recommandé par la RFC (Section 5.4, étape 2). L'algorithme de tri est, par ordre de priorité :
* `.path` le plus long
* `.creation` le plus ancien (avec une précision de 1 ms, identique à `Date`)
* `.creationIndex` le plus bas (pour aller au-delà de la précision de 1 ms)``` javascript
var cookies = [ /* unsorted array of Cookie objects */ ];
cookies = cookies.sort(cookieCompare);
Remarque: Comme le Date de JavaScript est limité à une précision de 1ms, des cookies créés dans la même milliseconde sont tout à fait possibles. Cela est particulièrement vrai lorsqu'on utilise l'option now avec .setCookie(). La propriété .creationIndex est un compteur global par processus, assigné lors de la construction avec new Cookie(). Cela préserve l'esprit du tri RFC: les cookies plus anciens passent en premier. Cela fonctionne très bien avec MemoryCookieStore, puisque les en-têtes Set-Cookie sont analysés dans l'ordre, mais cela peut ne pas convenir aux systèmes distribués. Les Stores sophistiqués souhaiteront peut-être définir cette valeur sur une autre horloge logique de sorte que si les cookies A et B sont créés dans la même milliseconde, mais que le cookie A est créé avant le cookie B, alors A.creationIndex < B.creationIndex. Si vous voulez modifier le compteur global, ce que vous ne devriez probablement pas faire, il est stocké dans Cookie.cookiesCreated.
permuteDomain(domain)Génère une liste de tous les domaines possibles que domainMatch() fait correspondre au paramètre. Peut être pratique pour implémenter des stores de cookies.
permutePath(path)Génère une liste de tous les chemins possibles que pathMatch() fait correspondre au paramètre. Peut être pratique pour implémenter des stores de cookies.
Exporté via tough.Cookie.
Cookie.parse(cookieString[, options])Analyse un cookie unique ou un en-tête HTTP Set-Cookie en un objet Cookie. Renvoie undefined si la chaîne ne peut pas être analysée.
Le paramètre options n'est pas requis et ne possède actuellement qu'une seule propriété:
true, active l'analyse des cookies sans clé comme =abc et =, qui ne sont pas conformes à la RFC.Si options n'est pas un objet, il est ignoré, ce qui signifie que vous pouvez utiliser Array#map avec lui.
Voici comment traiter le ou les en-têtes Set-Cookie dans une réponse HTTP/HTTPS 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'])];
_Note :_ dans la version 2.3.3, tough-cookie limitait le nombre d'espaces avant le `=` à 256 caractères. Cette limitation a depuis été supprimée.
Voir [Issue 92](https://github.com/salesforce/tough-cookie/issues/92)
### Propriétés
Propriétés de l'objet Cookie :
* _key_ - chaîne - le nom ou la clé du cookie (par défaut "")
* _value_ - chaîne - la valeur du cookie (par défaut "")
* _expires_ - `Date` - si défini, l'attribut `Expires=` du cookie (par défaut la chaîne `"Infinity"`). Voir `setExpires()`
* _maxAge_ - secondes - si défini, l'attribut `Max-Age=` _en secondes_ du cookie. Peut également être défini sur les chaînes `"Infinity"` et `"-Infinity"` pour la non-expiration et l'expiration immédiate, respectivement. Voir `setMaxAge()`
* _domain_ - chaîne - l'attribut `Domain=` du cookie
* _path_ - chaîne - le `Path=` du cookie
* _secure_ - booléen - l'indicateur `Secure` du cookie
* _httpOnly_ - booléen - l'indicateur `HttpOnly` du cookie
* _extensions_ - `Array` - tous les attributs de cookie non reconnus sous forme de chaînes (même s'ils contiennent des signes égaux)
* _creation_ - `Date` - quand ce cookie a été construit
* _creationIndex_ - nombre - défini à la construction, utilisé pour fournir une plus grande précision de tri (veuillez consulter `cookieCompare(a,b)` pour une explication complète)
Après qu'un cookie a été transmis via `CookieJar.setCookie()`, il aura les attributs supplémentaires suivants :
* _hostOnly_ - booléen - s'agit-il d'un cookie réservé à un hôte (c'est-à-dire qu'aucun champ Domain n'a été défini, mais qu'il a été plutôt implicite)
* _pathIsDefault_ - booléen - si vrai, il n'y avait aucun champ Path sur le cookie et `defaultPath()` a été utilisé pour en dériver un.
* _creation_ - `Date` - **modifié** de la construction au moment où le cookie a été ajouté au jar
* _lastAccessed_ - `Date` - dernière fois que le cookie a été accédé. Affectera le nettoyage des cookies une fois implémenté. L'utilisation de `cookiejar.getCookies(...)` mettra à jour cet attribut.
### `Cookie([{properties}])`
Reçoit un objet d'options qui peut contenir n'importe laquelle des propriétés Cookie ci-dessus, en utilisant la valeur par défaut pour les propriétés non spécifiées.
### `.toString()`
encode en une valeur d'en-tête Set-Cookie. Le champ cookie Expires est défini en utilisant `formatDate()`, mais est entièrement omis si `.expires` est `Infinity`.
### `.cookieString()`
encode en une valeur d'en-tête Cookie (c'est-à-dire les propriétés `.key` et `.value` jointes par '=').
### `.setExpires(String)`
définit l'expiration en fonction d'une chaîne de date transmise via `parseDate()`. Si parseDate renvoie `null` (c'est-à-dire qu'il ne peut pas analyser cette chaîne de date), `.expires` est défini sur `"Infinity"` (une chaîne).
### `.setMaxAge(number)`
définit le maxAge en secondes. Convertit `-Infinity` en `"-Infinity"` et `Infinity` en `"Infinity"` afin qu'il se sérialise correctement en JSON.
### `.expiryTime([now=Date.now()])`
### `.expiryDate([now=Date.now()])`
expiryTime() calcule les millisecondes absolues de l'époque Unix auxquelles ce cookie expire. expiryDate() fonctionne de manière similaire, sauf qu'elle renvoie un objet `Date`. Notez que dans les deux cas, le paramètre `now` doit être en millisecondes.
Max-Age a priorité sur Expires (conformément à la RFC). L'attribut `.creation` -- ou, par défaut, le paramètre `now` -- est utilisé pour décaler l'attribut `.maxAge`.
Si Expires (`.expires`) est défini, c'est cette valeur qui est renvoyée.
Sinon, `expiryTime()` renvoie `Infinity` et `expiryDate()` renvoie un objet `Date` pour "Tue, 19 Jan 2038 03:14:07 GMT" (date la plus tardive pouvant être exprimée par un `time_t` 32 bits ; la limite courante pour la plupart des agents utilisateurs).
### `.TTL([now=Date.now()])`
calcule le TTL relatif à `now` (millisecondes). Les mêmes règles de priorité que pour `expiryTime`/`expiryDate` s'appliquent.
Le "nombre" `Infinity` est renvoyé pour les cookies sans expiration explicite et `0` est renvoyé si le cookie est expiré. Sinon, un temps de vie en millisecondes est renvoyé.
### `.canonicalizedDomain()`
### `.cdomain()`
renvoie le champ `.domain` canonicalisé. Ce champ est en minuscules et encodé en punycode (RFC3490) si le domaine contient des caractères non ASCII.
### `.toJSON()`
Pour plus de commodité lors de l'utilisation de `JSON.serialize(cookie)`. Renvoie un simple `Object` qui peut être sérialisé en JSON.
Toute propriété `Date` (c'est-à-dire `.expires`, `.creation` et `.lastAccessed`) est exportée au format ISO (`.toISOString()`).
**REMARQUE** : les propriétés `Cookie` personnalisées seront ignorées. Dans tough-cookie 1.x, comme aucune méthode `.toJSON` n'était explicitement définie, toutes les propriétés énumérables étaient capturées. Si vous souhaitez qu'une propriété soit sérialisée, ajoutez le nom de la propriété au tableau `Cookie.serializableProperties`.
### `Cookie.fromJSON(strOrObj)`
Fait l'inverse de `cookie.toJSON()`. Si une chaîne est transmise, elle sera d'abord analysée par `JSON.parse()`.
Toute propriété `Date` (c'est-à-dire `.expires`, `.creation` et `.lastAccessed`) est analysée via `Date.parse()`, et non via `parseDate` de tough-cookie, car ce sont des horodatages de type JavaScript/JSON qui sont traités à cette couche.
Renvoie `null` en cas d'erreur d'analyse JSON.
### `.clone()`
Effectue un clonage profond de ce cookie, exactement implémenté comme `Cookie.fromJSON(cookie.toJSON())`.
### `.validate()`
Statut : *EN COURS*. Fonctionne pour certaines choses, mais n'est en aucun cas exhaustif.
valide les attributs du cookie pour la correction sémantique. Utile pour la vérification de type "lint" des en-têtes Set-Cookie que vous générez. Pour l'instant, il renvoie un booléen, mais pourrait éventuellement renvoyer une chaîne de raison -- vous pouvez préparer l'avenir avec cette construction :``` javascript
if (cookie.validate() === true) {
// it's tasty
} else {
// yuck!
}
Exporté via tough.CookieJar.
CookieJar([store],[options])Utilisez simplement new CookieJar(). Si vous souhaitez utiliser un store personnalisé, passez-le au constructeur, sinon un MemoryCookieStore sera créé et utilisé.
L'objet options peut être omis et peut avoir les propriétés suivantes :
true - rejette les cookies avec des domaines comme « com » et « co.uk »false - accepte les cookies malformés comme bar et =bar, qui ont un nom vide implicite.
Ce n'est pas dans le standard, mais c'est parfois utilisé sur le Web et c'est accepté par la plupart des navigateurs.Comme ce module voudrait éventuellement prendre en charge des CookieJars en base de données / à distance / etc., le style de passage par continuation est utilisé pour les méthodes de CookieJar.
.setCookie(cookieOrString, currentUrl, [{options},] cb(err,cookie))Tente de définir le cookie dans le cookie jar. Si l'opération échoue, une erreur sera transmise à la fonction de rappel cb ; sinon, le cookie est transmis. Le cookie aura des propriétés .creation, .lastAccessed et .hostOnly mises à jour.
L'objet options peut être omis et peut avoir les propriétés suivantes :
true - indique s'il s'agit d'une API HTTP ou non-HTTP. Affecte les cookies HttpOnly.https: ou wss: alors la valeur par défaut est true, sinon false.new Date() - ce qui doit être utilisé pour l'heure de création/accès des cookiesfalse - ignore silencieusement les erreurs d'analyse et les domaines invalides. Les erreurs de Store ne sont pas ignorées par cette option.Conformément au RFC, la propriété .hostOnly est définie s'il n'y avait pas de paramètre « Domain= » dans la chaîne du cookie (ou si .domain était null sur l'objet Cookie). Dans ce cas, la propriété .domain est définie sur le nom d'hôte complet de currentUrl. La correspondance de ce cookie exige une correspondance exacte du nom d'hôte (et non un domainMatch comme d'habitude).
.setCookieSync(cookieOrString, currentUrl, [{options}])Version synchrone de setCookie ; ne fonctionne qu'avec les stores synchrones (par exemple le MemoryCookieStore par défaut).
.getCookies(currentUrl, [{options},] cb(err,cookies))Récupère la liste des cookies pouvant être envoyés dans un en-tête Cookie pour l'url actuelle.
Si une erreur est rencontrée, elle est transmise comme err à la fonction de rappel ; sinon, un Array d'objets Cookie est transmis. Le tableau est trié avec cookieCompare() sauf si l'option {sort:false} est fournie.
L'objet options peut être omis et peut avoir les propriétés suivantes :
true - indique s'il s'agit d'une API HTTP ou non-HTTP. Affecte les cookies HttpOnly.https: ou wss: alors la valeur par défaut est true, sinon false.new Date() - ce qui doit être utilisé pour l'heure de création/accès des cookiestrue - vérifie le délai d'expiration des cookies et supprime de manière asynchrone les cookies expirés du store. Utiliser false renverra les cookies expirés et ne les supprimera pas du store (ce qui est potentiellement utile pour rejouer des en-têtes Set-Cookie).false - si true, ne limite pas les cookies par chemin. Le comportement par défaut utilise une délimitation par chemin conforme au RFC. Remarque : peut ne pas être pris en charge par le store sous-jacent (le MemoryCookieStore par défaut le prend en charge).La propriété .lastAccessed des cookies retournés aura été mise à jour.
.getCookiesSync(currentUrl, [{options}])Version synchrone de getCookies ; ne fonctionne qu'avec les stores synchrones (par exemple le MemoryCookieStore par défaut).
.getCookieString(...)Accepte les mêmes options que .getCookies() mais transmet à la fonction de rappel une chaîne adaptée à un en-tête Cookie plutôt qu'un tableau. Elle se contente de mapper le tableau Cookie via .cookieString().
.getCookieStringSync(...)Version synchrone de getCookieString ; ne fonctionne qu'avec les stores synchrones (par exemple le MemoryCookieStore par défaut).
.getSetCookieStrings(...)Retourne un tableau de chaînes adaptées aux en-têtes Set-Cookie. Accepte les mêmes options que .getCookies(). Elle se contente de mapper le tableau de cookies via .toString().
.getSetCookieStringsSync(...)Version synchrone de getSetCookieStrings ; ne fonctionne qu'avec les stores synchrones (par exemple le MemoryCookieStore par défaut).
.serialize(cb(err,serializedObject))Sérialise le Jar si le store sous-jacent prend en charge .getAllCookies.
REMARQUE : les propriétés Cookie personnalisées seront ignorées. Si vous souhaitez qu'une propriété soit sérialisée, ajoutez le nom de la propriété au tableau Cookie.serializableProperties.
Voir [Format de sérialisation].
.serializeSync()Version synchrone de .serialize
.toJSON()Alias de .serializeSync() pour faciliter l'utilisation de JSON.stringify(cookiejar).
CookieJar.deserialize(serialized, [store], cb(err,object))Un nouveau Jar est créé et les cookies sérialisés sont ajoutés au store sous-jacent. Chaque Cookie est ajouté via store.putCookie dans l'ordre dans lequel ils apparaissent dans la sérialisation.
L'argument store est facultatif, mais devrait être une instance de Store. Par défaut, une nouvelle instance de MemoryCookieStore est créée.
Par commodité, si serialized est une chaîne, elle est d'abord passée par JSON.parse. Si cela lève une erreur, celle-ci est transmise à la fonction de rappel.
CookieJar.deserializeSync(serialized, [store])Version synchrone de .deserialize. Remarque : le store doit être synchrone pour que cela fonctionne.
CookieJar.fromJSON(string)Alias de .deserializeSync pour assurer la cohérence avec Cookie.fromJSON().
.clone([store,]cb(err,newJar))Produit un clone profond de ce jar. Les modifications apportées à l'original n'affecteront pas le clone, et vice versa.
L'argument store est facultatif, mais devrait être une instance de Store. Par défaut, une nouvelle instance de MemoryCookieStore est créée. Le transfert entre types de stores est pris en charge tant que la source implémente .getAllCookies() et que la destination implémente .putCookie().
.cloneSync([store])Version synchrone de .clone, retournant une nouvelle instance de CookieJar.
L'argument store est facultatif, mais doit être une instance de Store synchrone s'il est spécifié. S'il n'est pas passé, une nouvelle instance de MemoryCookieStore est utilisée.
La source et la destination doivent toutes deux être des Store synchrones. Si l'un des stores ou les deux sont asynchrones, utilisez .clone à la place. Rappelons que MemoryCookieStore prend en charge à la fois les appels d'API synchrones et asynchrones.
.removeAllCookies(cb(err))Supprime tous les cookies du jar.
Il s'agit d'une nouvelle fonctionnalité rétrocompatible de tough-cookie version 2.5, donc tous les stores ne l'implémenteront pas efficacement. Pour les stores qui n'implémentent pas removeAllCookies, le repli consiste à appeler removeCookie après getAllCookies. Si getAllCookies échoue ou n'est pas implémenté dans le Store, cette erreur est retournée. Si un ou plusieurs appels à removeCookie échouent, seule la première erreur est retournée.
.removeAllCookiesSync()Version synchrone de .removeAllCookies()
Classe de base pour les stores CookieJar. Disponible sous la forme tough.Store.
Le modèle de stockage de chaque instance CookieJar peut être remplacé par une implémentation personnalisée. Le défaut est MemoryCookieStore, que l'on trouve dans le fichier lib/memstore.js. L'API utilise le style de passage par continuation pour permettre des stores asynchrones.
Les stores doivent hériter de la classe de base Store, disponible via require('tough-cookie').Store.
Les stores sont asynchrones par défaut, mais si store.synchronous est défini à true, alors les méthodes *Sync sur l'instance du CookieJar contenant peuvent être utilisées (cependant, le style de passage par continuation
Tous les paramètres domain auront été normalisés avant l'appel.
Le store de cookies doit avoir toutes les méthodes suivantes.
store.findCookie(domain, path, key, cb(err,cookie))Récupère un cookie avec le domaine, le chemin et la clé (a.k.a. le nom) donnés. Le RFC stipule qu'exactement un de ces cookies devrait exister dans un store. Si le store utilise le versionnage, cela signifie que le cookie le plus récent de ce type devrait être retourné.
La fonction de rappel prend une erreur et l'objet Cookie résultant. Si aucun cookie n'est trouvé, null DOIT être passé à la place (c'est-à-dire pas une erreur).
store.findCookies(domain, path, cb(err,cookies))Localise les cookies correspondant au domaine et au chemin donnés. Cette méthode est le plus souvent appelée dans le contexte de cookiejar.getCookies() ci-dessus.
Si aucun cookie n'est trouvé, un tableau vide DOIT être passé à la fonction de rappel.
La liste résultante sera vérifiée pour son applicabilité à la requête actuelle conformément au RFC (correspondance de domaine, correspondance de chemin, indicateur http-only, indicateur secure, expiration, etc.). Il est donc acceptable d'utiliser un algorithme de recherche optimiste lors de l'implémentation de cette méthode. Cependant, l'algorithme de recherche utilisé DEVRAIT tenter de trouver les cookies qui correspondent au domaine via domainMatch() et au chemin via pathMatch() afin de limiter le nombre de vérifications à effectuer.
Depuis la version 0.9.12, l'option allPaths de cookiejar.getCookies() ci-dessus fera en sorte que le chemin soit null ici. Si le chemin est null, la correspondance de chemin NE DOIT PAS être effectuée (c'est-à-dire uniquement la correspondance de domaine).
store.putCookie(cookie, cb(err))Ajoute un nouveau cookie au store. L'implémentation DEVRAIT remplacer tout cookie existant ayant les mêmes propriétés .domain, .path et .key -- selon la nature de l'implémentation, il est possible qu'un putCookie en double se produise entre l'appel à fetchCookie et putCookie.
L'objet cookie NE DOIT PAS être modifié ; l'appelant aura déjà mis à jour les propriétés .creation et .lastAccessed.
Passez une erreur si le cookie ne peut pas être stocké.
store.updateCookie(oldCookie, newCookie, cb(err))Met à jour un cookie existant. L'implémentation DOIT mettre à jour la .value d'un cookie ayant le même domain, .path et .key. L'implémentation DEVRAIT vérifier que l'ancienne valeur dans le store est équivalente à oldCookie - la résolution du conflit dépend du store.
La propriété .lastAccessed sera toujours différente entre les deux objets (à la précision permise par l'horloge de JavaScript). .creation et .creationIndex sont tous deux garantis d'être identiques. Les stores PEUVENT ignorer ou différer le changement de .lastAccessed, au prix d'affecter la façon dont les cookies sont sélectionnés pour une suppression automatique (par exemple, le moins récemment utilisé, ce qui dépend de l'implémentation du store).
Les stores peuvent souhaiter optimiser le changement de la .value du cookie dans le store plutôt que de stocker un nouveau cookie. Si l'implémentation ne définit pas cette méthode, un stub qui appelle putCookie(newCookie,cb) sera ajouté à l'objet store.
Les objets newCookie et oldCookie NE DOIVENT PAS être modifiés.
Passez une erreur si le newCookie ne peut pas être stocké.
store.removeCookie(domain, path, key, cb(err))Supprime un cookie du store (voir les notes sur findCookie concernant la contrainte d'unicité).
L'implémentation NE DOIT PAS passer d'erreur si le cookie n'existe pas ; ne passez une erreur que si la suppression d'un cookie existant échoue.
store.removeCookies(domain, path, cb(err))Supprime les cookies correspondants du store. Le paramètre path est facultatif ; s'il est absent, cela signifie que tous les chemins d'un domaine doivent être supprimés.
Ne passez une erreur QUE si la suppression de cookies existants a échoué.
store.removeAllCookies(cb(err))Facultatif. Supprime tous les cookies du store.
Passez une erreur si un ou plusieurs cookies ne peuvent pas être supprimés.
Remarque : nouvelle méthode introduite dans tough-cookie version 2.5, donc tous les stores ne l'implémenteront pas, et certains stores peuvent choisir de ne pas l'implémenter.
store.getAllCookies(cb(err, cookies))Facultatif. Produit un Array de tous les cookies lors de jar.serialize(). Les éléments du tableau peuvent être de vrais objets Cookie ou des Object génériques avec la structure de données [Format de sérialisation].
Les cookies DEVRAIENT être retournés dans l'ordre de création pour préserver le tri via compareCookies(). À titre de référence, MemoryCookieStore triera par .creationIndex car il utilise de vrais objets Cookie en interne. Si vous ne retournez pas les cookies dans l'ordre de création, ils seront tout de même triés par heure de création, mais cela n'a qu'une précision de 1 ms. Voir compareCookies pour plus de détails.
Passez une erreur si la récupération échoue.
Remarque : tous les stores ne peuvent pas implémenter cette méthode en raison de limitations techniques, elle est donc facultative.
Hérite de Store.
Une implémentation de store synchrone CookieJar en mémoire uniquement, utilisée par défaut. Bien qu'il s'agisse d'une implémentation synchrone, elle est utilisable avec les formes synchrones et asynchrones de l'API CookieJar. Prend en charge la sérialisation, getAllCookies et removeAllCookies.
Voici quelques implémentations de Store créées et maintenues par la communauté. Elles ne sont pas officielles et nous ne nous en portons pas garants, mais vous pourriez être intéressé d'y jeter un œil :
db-cookie-store: SQL, y compris les bases de données basées sur SQLitefile-cookie-store: format de fichier de cookies Netscape sur disqueredis-cookie-store: Redistough-cookie-filestore: JSON sur disquetough-cookie-web-storage-store: localStorage et sessionStorage DOMREMARQUE : si vous souhaitez que des propriétés Cookie personnalisées soient sérialisées, ajoutez le nom de la propriété à 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 */
}
]
}
# Droits d'auteur et licence
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.