Bonne façon de supprimer les cookies côté serveur

Pour mon processus d'authentification, je crée un jeton unique lorsqu'un utilisateur se connecte et je le place dans un cookie qui est utilisé pour l'authentification.

Donc, j'enverrais quelque chose comme ça depuis le serveur:

Set-Cookie: token=$2a$12$T94df7ArHkpkX7RGYndcq.fKU.oRlkVLOkCBNrMilaSWnTcWtCfJC; path=/;

Ce qui fonctionne sur tous les navigateurs. Ensuite, pour supprimer un cookie, j'envoie un cookie similaire avec le expireschamp défini pour le 1er janvier 1970

Set-Cookie: token=$2a$12$T94df7ArHkpkX7RGYndcq.fKU.oRlkVLOkCBNrMilaSWnTcWtCfJC; path=/; expires=Thu, Jan 01 1970 00:00:00 UTC; 

Et cela fonctionne bien sur Firefox mais ne supprime pas le cookie sur IE ou Safari.

Alors, quelle est la meilleure façon de supprimer un cookie (sans JavaScript de préférence)? La méthode du "set-the-expires-in-the-past" semble volumineuse. Et aussi pourquoi cela fonctionne-t-il dans FF mais pas dans IE ou Safari?

L'envoi de la même valeur de cookie avec l' ; expiresajout ne détruira pas le cookie.

Invalidez le cookie en définissant une valeur vide et incluez également un expireschamp:

Set-Cookie: token=deleted; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT

Notez que vous ne pouvez pas forcer tous les navigateurs à supprimer un cookie. Le client peut configurer le navigateur de manière à ce que le cookie persiste, même s'il a expiré. Définir la valeur comme décrit ci-dessus résoudrait ce problème.

Au moment où j'écris cette réponse, la réponse acceptée à cette question semble indiquer que les navigateurs ne sont pas tenus de supprimer un cookie lorsqu'ils reçoivent un cookie de remplacement dont la Expiresvaleur est dans le passé. Cette affirmation est fausse. Le fait Expiresd'être dans le passé est le moyen standard et conforme aux spécifications de supprimer un cookie, et les agents utilisateurs sont tenus par la spécification de le respecter.

L'utilisation d'un Expiresattribut dans le passé pour supprimer un cookie est correcte et constitue le moyen de supprimer les cookies dicté par la spécification. La section des exemples de la RFC 6255 indique:

Enfin, pour supprimer un cookie, le serveur renvoie un en-tête Set-Cookie avec une date d'expiration dans le passé. Le serveur réussira à supprimer le cookie uniquement si l'attribut Chemin et domaine dans l'en-tête Set-Cookie correspond aux valeurs utilisées lors de la création du cookie.

La section Exigences de l'agent utilisateur comprend les exigences suivantes, qui, ensemble, ont pour effet qu'un cookie doit être immédiatement effacé si l'agent utilisateur reçoit un nouveau cookie avec le même nom dont la date d'expiration est dans le passé

11. Si [lors de la réception d'un nouveau cookie], le magasin de cookies contient un cookie avec le même nom, domaine et chemin que le cookie nouvellement créé:

    1. ...
    2. ...
    3. Mettez à jour l'heure de création du cookie nouvellement créé pour correspondre à l'heure de création de l'ancien cookie.
    4. Supprimez l'ancien cookie du magasin de cookies.

12. Insérez le cookie nouvellement créé dans le magasin de cookies.

Un cookie est "expiré" si le cookie a une date d'expiration dans le passé.

L'agent utilisateur DOIT expulser tous les cookies expirés du magasin de cookies si, à tout moment, un cookie expiré existe dans le magasin de cookies.

Les points 11-3, 11-4 et 12 ci-dessus signifient ensemble que lorsqu'un nouveau cookie est reçu avec le même nom, domaine et chemin, l'ancien cookie doit être effacé et remplacé par le nouveau cookie. Enfin, le point ci-dessous sur les cookies expirés indique en outre qu'après cela, le nouveau cookie doit également être immédiatement expulsé. La spécification n'offre aucune marge de manœuvre aux navigateurs sur ce point; si un navigateur offrait à l'utilisateur la possibilité de désactiver l'expiration des cookies, comme le suggère la réponse acceptée par certains navigateurs, alors ce serait en violation des spécifications. (Une telle fonctionnalité aurait également peu d'utilité, et pour autant que je sache, elle n'existe dans aucun navigateur.)

Pourquoi, alors, le PO de cette question a-t-il vu cette approche échouer? Bien que je n'ai pas dépoussiéré une copie d'Internet Explorer pour vérifier son comportement, je soupçonne que c'était parce que la Expiresvaleur de l'OP était mal formée! Ils ont utilisé cette valeur:

expires=Thu, Jan 01 1970 00:00:00 UTC;

Cependant, cela est syntaxiquement invalide de deux manières.

La section de syntaxe de la spécification stipule que la valeur de l' Expiresattribut doit être un

rfc1123 -date, défini dans la [RFC2616], section 3.3.1

En suivant le deuxième lien ci-dessus, nous trouvons ceci donné à titre d'exemple de format:

Sun, 06 Nov 1994 08:49:37 GMT

et constatez que la définition de syntaxe ...

1. exige que les dates soient écrites au format jour mois année , et non au format mois jour année tel qu'utilisé par le demandeur.

   Plus précisément, il définit rfc1123-datecomme suit:

   rfc1123-date = wkday "," SP date1 SP time SP "GMT"
   

   et définit date1comme ceci:

   date1        = 2DIGIT SP month SP 4DIGIT
                ; day month year (e.g., 02 Jun 1982)
   

et

2. ne permet pas UTCcomme fuseau horaire.

   La spécification contient la déclaration suivante sur les décalages de fuseau horaire acceptables dans ce format:

   Tous les horodatages HTTP DOIVENT être représentés en heure moyenne de Greenwich (GMT), sans exception.

   De plus, si nous approfondissons la spécification originale de ce format datetime, nous trouvons que dans sa spécification initiale dans https://tools.ietf.org/html/rfc822 , la section Syntaxe répertorie "UT" (signifiant "temps universel" ) comme valeur possible, mais ne pas la liste non UTC (temps universel coordonné) comme valide. Autant que je sache, utiliser "UTC" dans ce format de date n'a jamais été valide; ce n'était pas une valeur valide lorsque le format a été spécifié pour la première fois en 1982, et la spécification HTTP a adopté une version strictement plus restrictive du format en interdisant l'utilisation de toutes les valeurs de "zone" autres que "GMT".

Si le demandeur de question ici avait utilisé à la place un Expiresattribut comme celui-ci , alors:

expires=Thu, 01 Jan 1970 00:00:00 GMT;

alors cela aurait probablement fonctionné.

Définir «expire» sur une date passée est la méthode standard pour supprimer un cookie.

Votre problème est probablement dû au fait que le format de la date n'est pas conventionnel. IE attend probablement GMT uniquement.

Utilisez Max-Age = -1 plutôt que "Expire". Il est plus court, moins pointilleux sur la syntaxe et Max-Age a de toute façon la priorité sur Expires.

Pour la mise en œuvre de GlassFish Jersey JAX-RS, j'ai résolu ce problème par la méthode commune qui décrit tous les paramètres communs. Au moins trois des paramètres doivent être égaux: nom (= "nom"), chemin (= "/") et domaine (= null):

public static NewCookie createDomainCookie(String value, int maxAgeInMinutes) {
    ZonedDateTime time = ZonedDateTime.now().plusMinutes(maxAgeInMinutes);
    Date expiry = time.toInstant().toEpochMilli();
    NewCookie newCookie = new NewCookie("name", value, "/", null, Cookie.DEFAULT_VERSION,null, maxAgeInMinutes*60, expiry, false, false);
    return newCookie;
}

Et utilisez-le de la manière courante pour définir un cookie:

NewCookie domainNewCookie = RsCookieHelper.createDomainCookie(token, 60);
Response res = Response.status(Response.Status.OK).cookie(domainNewCookie).build();

et pour supprimer le cookie:

NewCookie domainNewCookie = RsCookieHelper.createDomainCookie("", 0);
Response res = Response.status(Response.Status.OK).cookie(domainNewCookie).build();