diff options
| author | cbentzel@chromium.org <cbentzel@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-09-11 14:03:30 +0000 |
|---|---|---|
| committer | cbentzel@chromium.org <cbentzel@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-09-11 14:03:30 +0000 |
| commit | eca50e128ff1bc41bc0cc1d3fdf2e015ba459d4c (patch) | |
| tree | ae0368388f38766781c5ddff86c9e0e2c0c9c362 /base/waitable_event_win.cc | |
| parent | 4630db4630bc415cc3b7be70bce87160559810df (diff) | |
| download | chromium_src-eca50e128ff1bc41bc0cc1d3fdf2e015ba459d4c.zip chromium_src-eca50e128ff1bc41bc0cc1d3fdf2e015ba459d4c.tar.gz chromium_src-eca50e128ff1bc41bc0cc1d3fdf2e015ba459d4c.tar.bz2 | |
Fix multi-round authentication.
In the case of Negotiate, authentication can look like
C: GET
S: 401, WWW-Authenticate: Negotiate
C: GET, WWW-Authorization: Negotiate <client_token_1>
S: 401, WWW-Authenticate: Negotiate <server_token_1>
C: GET, WWW-Authorization: Negotiate <client_token_2>
S: 401, WWW-Authenticate: Negotiate <server_token_2>
on that third challenge, the handler was reported as being in "the final round" and this was treated as a rejection of the authentication attempt. After that, the new challenge token was used by a new auth handler that hadn't established a security context, and an ERR_INVALID_HANDLE would be returned.
This CL also does some prep work to correctly handle the "stale=true" value for Digest authentication, but I decided to defer the HttpAuthCache changes needed for that to a separate CL since this was large enough.
BUG=53282
TEST=net_unittests. Unfortunately, I haven't been able to set up a proxy/server to do more than two auth challenges, but this does happen in the wild.
Review URL: http://codereview.chromium.org/3360017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59188 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'base/waitable_event_win.cc')
0 files changed, 0 insertions, 0 deletions