get/set channel id/token-binding info using chrome-remote-interface |
|||||
Issue descriptionChrome Version : 67.0.3396.99 Background: We want to use browser for some automation in headless mode. Our use case requires user authentication. Our tool would bring up browser with new/empty profile and ask user to sign in. Then it would retrieve cookies through chrome-remote-interface and save it to json file. It would then run browser in headless mode with new/empty profile and inject those cookies through chrome-remote-interface. Issue: This works for all accounts we tried except corp @google.com accounts. I think this is because of channel-id feature, which is similar and would be (soon?) replaced with token-binding feature. Headless chrome doesn't save/restore channel ids to/from database. And there's no api to get/set them in a similar way as cookies using chrome-remote-interface. I think one of these options could solve our issue: 1. (preferred) add chrome-remote-interface api to get/set channel ids/token-binding ids 2. make headless chrome restore channel ids from database, so that we could reuse 'profile/Default/Origin Bound Certs' database file from regular chrome profile. 3. export chrome cmdline flag to disable channel id feature. Not sure if it will work. If this feature is disabled will it stop checking channel ids for auth or will auth stop working at all? But I guess this one would be the easiest to implement. Easiest way to reproduce: 1. google-chrome --user-data-dir=profile https://myaccount.google.com 2. sign-in with @google.com, close chrome. 3. mkdir -p profile2/Default/ && cp profile/Default/Cookies profile2/Default && google-chrome --user-data-dir=profile2 https://myaccount.google.com 4. Observe that user is signed out. Close chrome. 5. cp 'profile/Default/Origin Bound Certs' profile2/Default && google-chrome --user-data-dir=profile2 https://myaccount.google.com 6. Observe that user is signed in. Close chrome. 7. google-chrome --headless --remote-debuggin-port=9222 --user-data-dir=profile2 https://myaccount.google.com 8. Connect to localhost:9222 and observe that user is logged out. UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
,
Jul 19
Thanks for filling the issue... As per comment#0 the issue isn't reproducible from our end hence adding label "TE-NeedsTriageHelp" and requesting someone from respective team to have a look into this for further triaging it. Thanks!
,
Oct 10
,
Oct 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/14f0d10aebd5bd5d0098582b0420ca8031f5a8de commit 14f0d10aebd5bd5d0098582b0420ca8031f5a8de Author: Andrey Kosyakov <caseq@chromium.org> Date: Mon Oct 15 18:45:59 2018 Headless: support cookie encryption - enable cookie encryption by default (use --disable-cookie-encryption to turn it off); - configure OSCrypt iff cookie encryption is enabled and profile path is set (there was a bug there, but it was masked by cookie encryption being disabled); - properly configure SSL channel id storage; - use mock keychain on MacOSX Bug: 864744 Change-Id: Ice97864bb80d8988e3e090310b35c509031a8e7d Reviewed-on: https://chromium-review.googlesource.com/c/1274199 Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Andrey Kosyakov <caseq@chromium.org> Cr-Commit-Position: refs/heads/master@{#599696} [modify] https://crrev.com/14f0d10aebd5bd5d0098582b0420ca8031f5a8de/headless/BUILD.gn [modify] https://crrev.com/14f0d10aebd5bd5d0098582b0420ca8031f5a8de/headless/app/headless_shell.cc [modify] https://crrev.com/14f0d10aebd5bd5d0098582b0420ca8031f5a8de/headless/app/headless_shell_switches.cc [modify] https://crrev.com/14f0d10aebd5bd5d0098582b0420ca8031f5a8de/headless/app/headless_shell_switches.h [modify] https://crrev.com/14f0d10aebd5bd5d0098582b0420ca8031f5a8de/headless/lib/browser/headless_request_context_manager.cc [modify] https://crrev.com/14f0d10aebd5bd5d0098582b0420ca8031f5a8de/headless/lib/browser/headless_request_context_manager.h
,
Dec 20
This is fixed by the commit above -- the headless chrome just needs to share the profile directory with the headfull instance woth this to work (i.e. solution #2).
,
Dec 20
Issue 915543 has been merged into this issue. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by viswa.karala@chromium.org
, Jul 18