Invalidate credentials if the server rejects them.

net/http/http_auth_handler_digest.cc

 // Copyright (c) 2010 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "net/http/http_auth_handler_digest.h"
 
 #include <string>
 
 #include "base/logging.h"
 #include "base/md5.h"
@@ skipping 96 matching lines @@
 HttpAuth::AuthorizationResult HttpAuthHandlerDigest::HandleAnotherChallenge(
     HttpAuth::ChallengeTokenizer* challenge) {
   // Even though Digest is not connection based, a "second round" is parsed
   // to differentiate between stale and rejected responses.
   // Note that the state of the current handler is not mutated - this way if
   // there is a rejection the realm hasn't changed.
   if (!LowerCaseEqualsASCII(challenge->scheme(), "digest"))
     return HttpAuth::AUTHORIZATION_RESULT_INVALID;
 
   HttpUtil::NameValuePairsIterator parameters = challenge->param_pairs();
+  std::string realm;
 
-  // Try to find the "stale" value.
+  // Try to find the "stale" value, and also keep track of the realm
+  // for the new challenge.
   while (parameters.GetNext()) {
-    if (!LowerCaseEqualsASCII(parameters.name(), "stale"))
-      continue;
-    if (LowerCaseEqualsASCII(parameters.value(), "true"))
-      return HttpAuth::AUTHORIZATION_RESULT_STALE;
+    if (LowerCaseEqualsASCII(parameters.name(), "stale")) {
+      if (LowerCaseEqualsASCII(parameters.value(), "true"))
+        return HttpAuth::AUTHORIZATION_RESULT_STALE;

[wtc, 2011/02/22 23:17:32]

IMPORTANT: what if the new challenge has both stale=true
and a different realm?  Can that happen?

[cbentzel, 2011/02/23 14:49:54]

It could happen, but it seems unexpected. It seems like it would indicate that
the specified realm has stale credentials - not the one that we previously
issued a challenge for. I'll see if the RFC or httpbis mentions this corner
case.

[asanka, 2011/02/23 18:06:40]

RFC 2617 states that the 'stale' value should only be set to 'true' if the
server "receives a request for which the nonce is invalid but with a valid
digest for that nonce (indicating that the client knows the correct
username/password)," and that the client "may wish to simply retry the request
with a new encrypted response, without reprompting the user for a new username
and password."

Based on that, I think giving precedence to the "stale=true" case and
disregarding a change in the realm is reasonable behavior.

+    } else if (LowerCaseEqualsASCII(parameters.name(), "realm")) {
+      realm = parameters.value();
+    }
   }
-
-  return HttpAuth::AUTHORIZATION_RESULT_REJECT;
+  return (realm_ != realm) ?
+      HttpAuth::AUTHORIZATION_RESULT_DIFFERENT_REALM :
+      HttpAuth::AUTHORIZATION_RESULT_REJECT;
 }
 
 bool HttpAuthHandlerDigest::Init(HttpAuth::ChallengeTokenizer* challenge) {
   return ParseChallenge(challenge);
 }
 
 int HttpAuthHandlerDigest::GenerateAuthTokenImpl(
     const string16* username,
     const string16* password,
     const HttpRequestInfo* request,
@@ skipping 229 matching lines @@
     // TODO(eroman): Supposedly IIS server requires quotes surrounding qop.
     authorization += ", qop=" + QopToString(qop_);
     authorization += ", nc=" + nc;
     authorization += ", cnonce=" + HttpUtil::Quote(cnonce);
   }
 
   return authorization;
 }
 
 }  // namespace net