[
https://issues.apache.org/jira/browse/HDFS-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569307#comment-13569307
]
Alejandro Abdelnur commented on HDFS-4457:
------------------------------------------
Daryn,
Regarding your concern about having a proxy in the middle, I don't see that as
a problem, when you have an HTTP proxy in between, the client still targets the
real server hostname, it is the HTTP stack in the client the one that redirects
the request to the proxy with the real server hostname used by the client. Then
in the server side (webhdfsNN) from the HTTP request you can infer the exact
name of the server used by the client (proxy or not).
Regarding NAT in the middle doing port redirection, that should not be an issue
either as the host:port information used by the client is transmitted in the
HTTP 'Host' header which contains both host:port used by the client when
opening the connection (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html,
section '14.23 Host') and this is required in HTTP/1.1.
Regarding your second concern, Is that really a problem, tokens are transient
and I would not expect the to be valid across system updates.
On the *fetchdt*, got it. Still, that requires spawning a JVM to get the token.
> WebHDFS obtains/sets delegation token service hostname using wrong config
> leading to issues when NN is configured with 0.0.0.0 RPC IP
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-4457
> URL: https://issues.apache.org/jira/browse/HDFS-4457
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: webhdfs
> Affects Versions: 1.1.1, 2.0.2-alpha
> Reporter: Alejandro Abdelnur
> Assignee: Alejandro Abdelnur
> Priority: Critical
> Attachments: HDFS_4457.patch, HDFS_4457.patch
>
>
> If the NameNode RPC address is configured with an wildcard IP 0.0.0.0, then
> delegationotkens are configured with 0.0.0.0 as service and this breaks
> clients trying to use those tokens.
> Looking at NamenodeWebHdfsMethods#generateDelegationToken() the problem is
> SecurityUtil.setTokenService(t, namenode.getHttpAddress());, tracing back
> what is being used to resolve getHttpAddress() the NameNodeHttpServer is
> resolving the httpAddress doing a httpAddress = new
> InetSocketAddress(bindAddress.getAddress(), httpServer.getPort());
> , and if using "0.0.0.0" in the configuration, you get 0.0.0.0 from
> bindAddress.getAddress().
> Normally (non webhdfs) this is not an issue because it is the responsibility
> of the client, but in the case of WebHDFS, WebHDFS does it before returning
> the string version of the token (it must be this way because the client may
> not be a java client at all and cannot manipulate the DelegationToken as
> such).
> The solution (thanks to Eric Sammer for helping figure this out) is for
> WebHDFS to use the exacty hostname that came in the HTTP request as the
> service to set in the delegation tokens.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
