Prawidłowy sposób usuwania plików cookie po stronie serwera

Na potrzeby procesu uwierzytelniania tworzę unikalny token, gdy użytkownik loguje się i umieszczam go w pliku cookie, który jest używany do uwierzytelniania.

Więc wysłałbym coś takiego z serwera:

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

Działa we wszystkich przeglądarkach. Następnie, aby usunąć plik cookie, wysyłam podobny plik cookie z expirespolem ustawionym na 1 stycznia 1970 r

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

Działa to dobrze w przeglądarce Firefox, ale nie usuwa pliku cookie w przeglądarce IE lub Safari.

Jaki jest więc najlepszy sposób na usunięcie pliku cookie (najlepiej bez JavaScript)? Metoda „set-the-expires-in-past” wydaje się nieporęczna. A także dlaczego to działa w FF, ale nie w IE czy Safari?

Wysłanie tej samej wartości pliku cookie z ; expiresdołączonym nie spowoduje zniszczenia pliku cookie.

Unieważnij plik cookie, ustawiając pustą wartość i dołącz również expirespole:

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

Pamiętaj, że nie możesz zmusić wszystkich przeglądarek do usunięcia pliku cookie. Klient może skonfigurować przeglądarkę w taki sposób, aby plik cookie trwał, nawet jeśli wygasł. Ustawienie wartości w sposób opisany powyżej rozwiązałoby ten problem.

W chwili, gdy piszę tę odpowiedź, przyjęta odpowiedź na to pytanie wydaje się wskazywać, że przeglądarki nie muszą usuwać pliku cookie w przypadku otrzymania zastępczego pliku cookie, którego Expireswartość należy do przeszłości. To twierdzenie jest fałszywe. Ustawienie Expiresna przeszłość to standardowy, zgodny ze specyfikacją sposób usuwania pliku cookie, a oprogramowanie użytkownika jest wymagane przez specyfikację, aby go przestrzegać.

Używanie Expiresatrybutu w przeszłości do usuwania pliku cookie jest poprawne i jest sposobem usuwania plików cookie podyktowanym przez specyfikację. W sekcji przykładów dokumentu RFC 6255 podano :

Na koniec, aby usunąć plik cookie, serwer zwraca nagłówek Set-Cookie z datą wygaśnięcia w przeszłości. Serwer pomyślnie usunie plik cookie tylko wtedy, gdy ścieżka i atrybut domeny w nagłówku Set-Cookie są zgodne z wartościami używanymi podczas tworzenia pliku cookie.

Sekcja Wymagania klienta użytkownika zawiera następujące wymagania, które łącznie powodują, że plik cookie musi zostać natychmiast usunięty, jeśli agent użytkownika otrzyma nowy plik cookie o tej samej nazwie, którego data ważności już minęła

11. Jeśli [podczas otrzymywania nowego pliku cookie] magazyn plików cookie zawiera plik cookie o tej samej nazwie, domenie i ścieżce, co nowo utworzony plik cookie:

    1. ...
    2. ...
    3. Zaktualizuj czas utworzenia nowo utworzonego pliku cookie, aby odpowiadał czasowi utworzenia starego pliku cookie.
    4. Usuń stare pliki cookie ze sklepu plików cookie.

12. Wstaw nowo utworzony plik cookie do magazynu plików cookie.

Plik cookie „wygasł”, jeśli ma datę ważności w przeszłości.

Klient użytkownika MUSI usunąć wszystkie wygasłe pliki cookie z magazynu plików cookie, jeśli w dowolnym momencie wygasły plik cookie znajduje się w magazynie plików cookie.

Punkty 11-3, 11-4 i 12 powyżej razem oznaczają, że po otrzymaniu nowego pliku cookie o tej samej nazwie, domenie i ścieżce stary plik cookie musi zostać usunięty i zastąpiony nowym. Wreszcie poniższy punkt dotyczący wygasłych plików cookie dodatkowo mówi, że po wykonaniu tej czynności nowy plik cookie również musi zostać natychmiast usunięty. Specyfikacja nie daje w tej kwestii żadnego miejsca dla przeglądarek; gdyby przeglądarka oferowała użytkownikowi opcję wyłączenia wygaśnięcia plików cookie, jak sugeruje to akceptowana odpowiedź w niektórych przeglądarkach, byłoby to niezgodne ze specyfikacją. (Taka funkcja również byłaby mało przydatna i o ile wiem, nie istnieje w żadnej przeglądarce).

Dlaczego więc w PO w tym pytaniu stwierdzono, że podejście to zawodziło? Chociaż nie odkurzyłem kopii Internet Explorera, aby sprawdzić jego zachowanie, podejrzewam, że było to spowodowane Expiresnieprawidłowym sformułowaniem wartości OP ! Użyli tej wartości:

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

Jednak jest to niepoprawne składniowo z dwóch powodów.

Sekcja składni specyfikacji mówi, że wartością Expiresatrybutu musi być

rfc1123 -date , zdefiniowana w [RFC2616], Sekcja 3.3.1

Podążając za drugim linkiem powyżej, znajdujemy to jako przykład formatu:

Sun, 06 Nov 1994 08:49:37 GMT

i przekonaj się, że definicja składni ...

1. wymaga, aby daty były zapisywane w formacie dzień miesiąc rok , a nie miesiąc dzień rok , jak jest to używane przez osobę zadającą pytania.

   W szczególności definiuje rfc1123-datew następujący sposób:

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

   i definiuje w date1ten sposób:

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

i

2. nie zezwala UTCjako strefa czasowa.

   Specyfikacja zawiera następujące stwierdzenie o tym, jakie przesunięcia stref czasowych są dopuszczalne w tym formacie:

   Wszystkie znaczniki daty / czasu HTTP MUSZĄ być przedstawione w czasie Greenwich (GMT), bez wyjątku.

   Co więcej, jeśli będziemy kopać głębiej w oryginalnej specyfikacji tego formatu datetime, okazuje się, że w jego początkowej specyfikacji w https://tools.ietf.org/html/rfc822 , że sekcja składni listy „UT” (czyli „czas uniwersalny” ) jako możliwej wartości, ale robi nie lista UTC (Coordinated Universal Time) jako ważny. O ile wiem, używanie „UTC” w tym formacie daty nigdy nie było ważne; nie była to prawidłowa wartość, kiedy format został po raz pierwszy określony w 1982 r., a specyfikacja HTTP przyjęła bardziej restrykcyjną wersję formatu, zakazując stosowania wszystkich wartości „strefy” innych niż „GMT”.

Jeżeli Pytający pytanie tutaj miał zamiast użył Expiresatrybutu jak to , a następnie:

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

to przypuszczalnie by zadziałało.

Ustawienie „wygasa” na przeszłą datę jest standardowym sposobem usunięcia pliku cookie.

Twój problem prawdopodobnie wynika z nietypowego formatu daty. IE prawdopodobnie oczekuje tylko czasu GMT.

Użyj Max-Age = -1 zamiast „Expires”. Jest krótszy, mniej wybredny w składni, a Max-Age i tak ma pierwszeństwo przed Expires.

Dla implementacji GlassFish Jersey JAX-RS rozwiązałem ten problem za pomocą wspólnej metody opisywania wszystkich wspólnych parametrów. Przynajmniej trzy parametry muszą być równe: nazwa (= "nazwa"), ścieżka (= "/") i domena (= 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;
}

I używaj tego powszechnego sposobu ustawiania plików cookie:

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

i usunąć plik cookie:

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