session cookies have an expiring date in 1969?
Reported by
jeremy.g...@gmail.com,
Jan 31 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36 Example URL: https://www.google.com/intl/fr/analytics/#?modal_active=none Steps to reproduce the problem: On any webpage 1. F12 to open the dev tools 2. Application 3. Search for a cookie that should be a session cookie (eg : the utmc cookie used by Google Analytics : https://developers.google.com/analytics/devguides/collection/analyticsjs/cookie-usage ) What is the expected behavior? What went wrong? The "Expires" value should be "session" The current value is related to 1969 (?) Did this work before? N/A Chrome version: 64.0.3282.119 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
Jan 31 2018
,
Jan 31 2018
,
Feb 8 2018
Also facing the same issue on Chrome version 64.0.3282.140 Mac OS X 10.12.6
,
Apr 2 2018
Also facing the same issue here. I believe this is an old bug first reported 10 years ago? Chrome version 64.0.3282.186 Mac OS X 10.12.6
,
Apr 4 2018
I am experiencing the same issue. The same bug was asked in stackoverflow https://stackoverflow.com/questions/42522736/error-in-cookie-expiration-date-for-chrome and https://stackoverflow.com/questions/10890102/c-sharp-asp-net-cookie-expiration-date-in-chrome. In the second link, the answerer Faraday said IN 2012 that it was only a display bug and the session cookie semantics were respected. But in 2018, with Google Chrome version 65.0.3325.181, there is not only a bug in the display (still showing expires as 1969 for session cookie) but also the session cookie persists even after computer reboots.
,
Apr 10 2018
I reproduced this indeed in stable and canary, this is very confusing. FYI, in Firefox DevTools, the value of this column is displayed as "Expires on": "Session" instead of showing the fake date. Based on the symptoms, it seems that session cookies have internally set expiry date `-1`, which treated as a UTC timestamp from 1 Jan 1970 becomes 31 Dec 1969 23:59:59 in DevTools.
,
Apr 13 2018
BTW #comment 6: the fact that session cookie persists after computer reboot is probably https://bugs.chromium.org/p/chromium/issues/detail?id=128513 which is "won't fix" (see also https://stackoverflow.com/questions/10617954/chrome-doesnt-delete-session-cookies)
,
Apr 13 2018
Going to go ahead and remove the cookies label - this seems like strictly a devtools issue, though perhaps the cookies API could be clearer.
,
Oct 12
,
Dec 19
,
Dec 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2996a103460ff24ce019da4f99f9700282c3f341 commit 2996a103460ff24ce019da4f99f9700282c3f341 Author: Harley Li <hhli@chromium.org> Date: Thu Dec 20 01:49:35 2018 [DevTools] Application > Cookies: handle invalid expiration date If cookie.expires() returns a negative number, DevTools should display it as "N/A" as opposed to an ISO time string at some point in 1969. The dates use the UTC+0 time zone, as indicated by the 'Z' suffixes. Change-Id: I7176636d8be6afbc11aa15ab33072baf7a0c2789 Bug: 807661 Reviewed-on: https://chromium-review.googlesource.com/c/1379041 Commit-Queue: Haihong Li (Harley) <hhli@chromium.org> Reviewed-by: Erik Luo <luoe@chromium.org> Cr-Commit-Position: refs/heads/master@{#618070} [modify] https://crrev.com/2996a103460ff24ce019da4f99f9700282c3f341/third_party/blink/renderer/devtools/front_end/cookie_table/CookiesTable.js [modify] https://crrev.com/2996a103460ff24ce019da4f99f9700282c3f341/third_party/blink/web_tests/http/tests/devtools/components/cookies-table-expected.txt [modify] https://crrev.com/2996a103460ff24ce019da4f99f9700282c3f341/third_party/blink/web_tests/http/tests/devtools/components/cookies-table.js |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by mmenke@chromium.org
, Jan 31 2018Labels: -OS-Windows -Pri-2 Pri-3