[
https://issues.apache.org/jira/browse/IMPALA-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16944843#comment-16944843
]
ASF subversion and git services commented on IMPALA-9001:
---------------------------------------------------------
Commit 9cd1d72194391d18d4949ee8c2b86f32efa8a8ab in impala's branch
refs/heads/master from Thomas Tauber-Marshall
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=9cd1d72 ]
IMPALA-9001: Fix SPNEGO for requests with no 'Authorization'
When SPNEGO was first implemented for both hs2 and the webui, the way
we handled requests that did not include an "Authorization" header was
to pass an empty string to gss-api and then return a
"WWW-Authenticate: Negotiate <token>" where <token> was whatever was
returned by gss-api.
This works with some clients, but appears to fail with others. This
patch modifies the behavior to not send the <token> with the initial
WWW-Authenticate, which works with all tested clients.
Testing:
- Tested with curl, Knox, and Java's HttpURLConnection API.
Change-Id: Id9b6ac99b799324ec22e95fd1eb022d5ad6f54bd
Reviewed-on: http://gerrit.cloudera.org:8080/14352
Reviewed-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com>
Tested-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com>
> Fix SPNEGO for requests with no "Authorization"
> -----------------------------------------------
>
> Key: IMPALA-9001
> URL: https://issues.apache.org/jira/browse/IMPALA-9001
> Project: IMPALA
> Issue Type: Bug
> Affects Versions: Impala 3.4.0
> Reporter: Thomas Tauber-Marshall
> Assignee: Thomas Tauber-Marshall
> Priority: Critical
>
> When SPNEGO was first implemented for both hs2 and the webui, the way we
> handled requests that did not include an "Authorization" header was to pass
> an empty string to gss-api and then return a "WWW-Authenticate: Negotiate
> <token>" where <token> was whatever was returned by gss-api.
> This seemed to work with the clients it was originally tested with, curl and
> Knox, but it has been found not to work with some other clients. In
> particular, the following stack trace has been observed when using java's
> HttpURLConnection API:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> sun.net.www.protocol.http.NegotiateAuthentication.nextToken(NegotiateAuthentication.java:252)
> at
> sun.net.www.protocol.http.NegotiateAuthentication.setHeaders(NegotiateAuthentication.java:209)
> at
> sun.net.www.protocol.http.HttpURLConnection.getServerAuthentication(HttpURLConnection.java:2507)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1719)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
> at
> java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
> ... 20 more
> {noformat}
> Through some experimentation and by comparing our behavior with other Hadoop
> components, I determined that sending the initial "WWW-Authenticate" with no
> token works for all (tested) clients. This is also consistent with the
> description of the SPNEGO protocol in this document:
> https://tools.ietf.org/html/rfc4559#section-4.1 which states "The initial
> WWW-Authenticate header will not carry any gssapi-data."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
