Refactor HttpNegotiate exposed status codes

net/android/java/src/org/chromium/net/HttpNegotiateConstants.java

Index: net/android/java/src/org/chromium/net/HttpNegotiateConstants.java
diff --git a/net/android/java/src/org/chromium/net/HttpNegotiateConstants.java b/net/android/java/src/org/chromium/net/HttpNegotiateConstants.java
index fa17647f4a0888144e68f83d8f7e39772b34bd40..fabb636ad55c942ef8e236a70eec88bb0d0b403c 100644
--- a/net/android/java/src/org/chromium/net/HttpNegotiateConstants.java
+++ b/net/android/java/src/org/chromium/net/HttpNegotiateConstants.java
@@ -4,6 +4,11 @@
 
 package org.chromium.net;
 
+import android.support.annotation.IntDef;
+
+import java.lang.annotation.Retention;
+import java.lang.annotation.RetentionPolicy;
+
 /**
  * Constants used by Chrome in SPNEGO authentication requests to the Android Account Manager.
  */
@@ -27,25 +32,57 @@
     // Prefix of token type. Full token type is "SPNEGO:HOSTBASED:<spn>"
     public static final String SPNEGO_TOKEN_TYPE_BASE = "SPNEGO:HOSTBASED:";
 
+    /** */
+    @IntDef({STATUS_CODE_OK, STATUS_CODE_REQUEST_ERROR, STATUS_CODE_AUTHENTICATOR_ERROR})
+    @Retention(RetentionPolicy.SOURCE)
+    public @interface NegotiateStatus {}
+
+    /**
+     * All OK. The returned token is valid.
+     */
+    public static final int STATUS_CODE_OK = 0;

[asanka, 2015/11/25 15:08:08]

For multi-round authentication schemes like Negotiate, we expect two kinds of
success codes:

  1. So far so good. Here's a token to send back to the server. I expect at
least one more round of token exchanges.

  2. Success. We are done. No more token exchanges are expected and this
authentication session should not be used any more.

From the perspective of an HTTP client, this isn't super important, because in
both cases the client has to send back the token (if there is one) in a suitable
authorization header. But if we are going to establish authentication contexts,
then the difference means that we can extract metadata about the established
context after the final success code.

[dgn, 2015/11/25 16:16:56]

Is this distinction made on the desktop? AFAIK on Android we just have one
success code and it's up to the server to require another token.

[asanka, 2015/11/25 20:10:08]

That depends on what the strategy is for handling an authentication session. If
we don't need to do any cleanup upon completion of a handshake, then //net
doesn't need to know the difference. This is something that //net doesn't do a
good job of currently and needs to be fixed.

Looking at
https://www.chromium.org/developers/design-documents/http-authentication/writ...
, it seems that the way to tear down a session is for the authenticator to not
specify a KEY_SPNEGO_CONTEXT key in the bundle. So I think we are okay with this
aspect of the API. I.e. the server can already signal the end of an
authentication session.

+
+    /**
+     * Request failed. It can be tried again.
+     * Return this to tell the browser to not retry until it is restarted.

[asanka, 2015/11/25 15:08:08]

Not sure what 'it' means here. Also the distinction we'd probably want to make
is:

 1. Permanent error. Don't call me again "for a while." This would be the case
where the authenticator doesn't have credentials.

 2. Target specific error. Don't call me again for this target "for a while."
This would be the case where the credentials can't be used to authenticate to
the specific target.

The state of the browser is irrelevant for authentication if the credentials are
supplied externally. Also the browser is unaware of the state of the
authenticator. Hence the browser can't decide whether or not to send a request
out based on whether the authenticator has restarted or not. There needs to be a
better signal.

[dgn, 2015/11/25 16:16:56]

'it' was referring to the browser, I wrote that based on the comments on the net
constant comments. But yes, it's not accurate and going for an explicitly vague
description seems better, since authenticators should not care about the
browser's state

[asanka, 2015/11/25 20:10:08]

Ok. But what does "Return this to tell the browser to not retry until it is
restarted" mean? I'm guessing that's a typo and that this error signals that the
browser should try to invoke the authenticator again if an authentication
challenge comes along for the same target?

+     */
+    public static final int STATUS_CODE_REQUEST_ERROR = 10;
+
+    /**
+     * Request failed. The authenticator is in a bad state and cannot resolve requests.
+     * Return this to tell the browser to not retry until it is restarted.
+     */
+    public static final int STATUS_CODE_AUTHENTICATOR_ERROR = 11;
+
     // Returned status codes
     // All OK. Returned token is valid.
+    @Deprecated
     public static final int OK = 0;
     // An unexpected error. This may be caused by a programming mistake or an invalid assumption.
+    @Deprecated
     public static final int ERR_UNEXPECTED = 1;
     // Request aborted due to user action.
+    @Deprecated
     public static final int ERR_ABORTED = 2;
     // An unexpected, but documented, SSPI or GSSAPI status code was returned.
+    @Deprecated
     public static final int ERR_UNEXPECTED_SECURITY_LIBRARY_STATUS = 3;
     // The server's response was invalid.
+    @Deprecated
     public static final int ERR_INVALID_RESPONSE = 4;
     // Credentials could not be established during HTTP Authentication.
+    @Deprecated
     public static final int ERR_INVALID_AUTH_CREDENTIALS = 5;
     // An HTTP Authentication scheme was tried which is not supported on this machine.
+    @Deprecated
     public static final int ERR_UNSUPPORTED_AUTH_SCHEME = 6;
     // (GSSAPI) No Kerberos credentials were available during HTTP Authentication.
+    @Deprecated
     public static final int ERR_MISSING_AUTH_CREDENTIALS = 7;
     // An undocumented SSPI or GSSAPI status code was returned.
+    @Deprecated
     public static final int ERR_UNDOCUMENTED_SECURITY_LIBRARY_STATUS = 8;
     // The identity used for authentication is invalid.
+    @Deprecated
     public static final int ERR_MALFORMED_IDENTITY = 9;
 }