Description
HADOOP-8883 made this change to KerberosAuthenticator
@@ -158,7 +158,7 @@ public class KerberosAuthenticator implements Authenticator { conn.setRequestMethod(AUTH_HTTP_METHOD); conn.connect(); - if (conn.getResponseCode() == HttpURLConnection.HTTP_OK) { + if (conn.getRequestProperty(AUTHORIZATION) != null && conn.getResponseCode() == HttpURLConnection.HTTP_OK) { LOG.debug("JDK performed authentication on our behalf."); // If the JDK already did the SPNEGO back-and-forth for // us, just pull out the token.
to fix OOZIE-1010. However, as aklochkov pointed out recently, this inadvertently made the if statement always false because it turns out that the JDK excludes some headers, including the "Authorization" one that we're checking (see discussion here). This means that it was always either calling doSpnegoSequence(token); or getFallBackAuthenticator().authenticate(url, token);, which is actually the old behavior that existed before HADOOP-8855 changed it in the first place.
In any case, I tried removing the "Authorization" check and Oozie still works with and without Kerberos; the NPE reported in OOZIE-1010 has since been properly fixed due as a side effect for a similar issue in OOZIE-1368.
Attachments
Attachments
Issue Links
- breaks
-
HADOOP-10398 KerberosAuthenticator failed to fall back to PseudoAuthenticator after HADOOP-10078
- Resolved
-
OOZIE-2315 TestOozieCLI.testshareLibUpdate_withSecurity fails with Hadoop 2
- Closed
- is related to
-
OOZIE-800 Job start/kill gives authorization error
- Resolved
-
OOZIE-1010 Oozie CLI throws an NPE with Hadoop trunk with simple auth
- Resolved
-
HADOOP-8883 Anonymous fallback in KerberosAuthenticator is broken
- Closed
-
OOZIE-1368 Error message when using an incorrect oozie url with kerberos is misleading
- Closed
-
HADOOP-8855 SSL-based image transfer does not work when Kerberos is disabled
- Closed
- relates to
-
HADOOP-11467 KerberosAuthenticator can connect to a non-secure cluster
- Closed