diff options
| author | rmsousa@chromium.org <rmsousa@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2014-01-23 00:34:59 +0000 |
|---|---|---|
| committer | rmsousa@chromium.org <rmsousa@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2014-01-23 00:34:59 +0000 |
| commit | a62469bdfdab396a2e255e380fd9e322910b168b (patch) | |
| tree | 6c770a63c281730117601638c25b4bb526d11ae4 /content/OWNERS | |
| parent | 8ee5db3bb79ca9cc3ae1f7ac22375b4c63990793 (diff) | |
| download | chromium_src-a62469bdfdab396a2e255e380fd9e322910b168b.zip chromium_src-a62469bdfdab396a2e255e380fd9e322910b168b.tar.gz chromium_src-a62469bdfdab396a2e255e380fd9e322910b168b.tar.bz2 | |
Support sending client certificates when validating tokens.
I chose to add a new certificate auto-selection policy, because the existing certificate auto-selection is very coupled with Chrome. The existing AutoSelectCertificateUrls requires chrome/common/content_settings_pattern.h (which depends on other browser specific files, and is otherwise very browser-specific logic) to parse the URL pattern, and chrome/browser/chrome_content_browser_client.cc to match the certificate.
Also, URLFetcher doesn't support sending certificates, and supporting it is a strict non-goal ( https://codereview.chromium.org/136883010/ ), so I had to use the lower level URLRequest, and have tokenvalidator do its own buffering.
Finally, the client certificate store has some unpleasant lifetime requirements, so there are some hacks to deal with that as well.
BUG=315825
Review URL: https://codereview.chromium.org/133273025
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@246456 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'content/OWNERS')
0 files changed, 0 insertions, 0 deletions