New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 864744 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 20
Cc:
EstimatedDays: 0
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

get/set channel id/token-binding info using chrome-remote-interface

Project Member Reported by fuchedzhy@google.com, Jul 17

Issue description

Chrome 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

 
Labels: Needs-Triage-M67
Cc: phanindra.mandapaka@chromium.org
Labels: Triaged-ET TE-NeedsTriageHelp
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!
Status: Started (was: Unconfirmed)
Project Member

Comment 4 by bugdroid1@chromium.org, 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

Status: Fixed (was: Started)
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).
Cc: eseckler@chromium.org caseq@chromium.org skyos...@chromium.org susan.boorgula@chromium.org
 Issue 915543  has been merged into this issue.

Sign in to add a comment