Reopening tab on startup: Cookies not being sent after redirect.
Reported by
sylvain....@gmail.com,
Feb 28 2018
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Suppose I have a protected website https://foo.com/protected/ 2. when the user accesses it, there's a 302 redirect to https://foo.com/auth/ 3. here some persistent cookie is recognized by the server and the browser is redirected back to https://foo.com/protected/ with a 302 and a new session cookie 4. The Chrome preference "On start-up -> Continue where you left off" is active 5. Chrome is opened with a single tab on https://foo.com/protected/ 6. Chrome is closed 7. Chrome is opened again What is the expected behavior? Upon Chrome launch, only 3 requests should be made: - https://foo.com/protected/ : with response 302 to redirect to https://foo.com/auth/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/ - https://foo.com/protected/ : with response 200 OK What went wrong? there are 10 requests to https://foo.com/auth/ . The sequence is - https://foo.com/protected/ : with response 302 to redirect to https://foo.com/auth/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/ - https://foo.com/protected/ : with response 200 OK Did this work before? N/A Chrome version: 64.0.3282.186 Channel: stable OS Version: OS X 10.13.3 Flash Version: The cause seems linked to the fact that the 302 redirects from https://foo.com/auth/ to https://foo.com/protected/ contains anti-caching headers (cache-control: no-cache, no-store, max-age=0). If those headers are removed, then the behavior is as expected. Also, this happens only when launching Chrome, with "On start-up -> Continue where you left off" active. If Chrome is already running with no tab and we open a new page to https://foo.com/protected/ then the behavior is also correct. Other remark: if we don't redirect to the original URL but to a different one, then the behavior is also OK. Example: - https://foo.com/protected/ : with response 302 to redirect to https://foo.com/auth/ - https://foo.com/auth/ : with response 302 to redirect to https://foo.com/protected/otherpage - https://foo.com/protected/otherpage : with response 200 OK
,
Feb 28 2018
,
Mar 7 2018
Because of security reasons I cannot attach the log of the case I have encountered. I'll try to create a reproducer.
,
Mar 7 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 7 2018
Re-adding the Needs-Feedback label
,
Mar 9 2018
I finally created a reproducer : - go to http://chromebugreproducer.leslaurent.net/index.php - click on the button to remove the cookie - quit and launch Chrome (provided you have the "On start-up -> Continue where you left off" option active) - the page should say that there have been 10 redirects I attached the net log here too.
,
Mar 9 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 14 2018
I can reproduce this, not 100% consistently, but without too much difficulty. A text copy of the relevant event from net-internals is attached (Not including the entire log, because it includes cookies). Requets for index.php are being repeatedly served from the cache, despite the fact that 302 responses are not cacheable by default, and there are no caching directives. My guess, without digging further into it, is that this is more fallout from the cache lock removal effort. Upping this to P1.
,
Mar 14 2018
Sorry about that - I think that's wrong. This is likely caused by the SKIP_CACHE_VALIDATION LoadFlag being used on tab restore, and has nothing to do with the cache lock effort. Sorry about that! So this is entirely an interaction between session restore (Or, more generally, SKIP_CACHE_VALIDATION - which can also be used on back/forward navigations), the cache, and the way the website handles login.
,
Mar 14 2018
And to confirm, navigation back/forward after clearing the cookie does indeed reproduce this.
,
Mar 14 2018
This came up before with back/forward, and the suggestion was to use Vary:Cookie... (https://bugs.chromium.org/p/chromium/issues/detail?id=781584)
,
Apr 12 2018
Able to reproduce this issue as per steps mentioned in comment#6 on latest stable 65.0.3325.181, on latest beta 66.0.3359.81 and latest canary 67.0.3394.0 using Windows 10, Mac 10.13.3 and Ubuntu 14.04. NOTE: In 61.0.3163.0, 61.0.3163.100 after quitting chrome and re-opening seeing There has been 1 redirect(s) only. But from 62.0.3164.0 seeing There has been 10 redirect(s). Hence considered 61.0.3163.0 as Good build and 62.0.3164.0 as Bad Build. Good Build: 61.0.3163.0 Bad Build: 62.0.3164.0 Observing all bad builds on performing chromium and per-revision bisect even after changing range. Hence providing manual cl info. CR: https://chromium.googlesource.com/chromium/src/+log/61.0.3163.0..62.0.3164.0?pretty=fuller&n=10000 Suspecting Reviewed-on: https://chromium-review.googlesource.com/579188 from changelog. @ rhalavati: Please confirm the bug and help in re-assigning if this is not related to your change. Thanks!
,
Apr 12 2018
This CL cannot be the root of this error. It just changes traffic annotations protobuf and updates all previous usages of it. The protobuf has NO effect on how requests are handled and there are only DCHECKs in the code to ensure annotations are provided. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by xunji...@chromium.org
, Feb 28 2018