[ 
https://issues.apache.org/jira/browse/HDFS-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arpit Agarwal resolved HDFS-5275.
---------------------------------

    Resolution: Invalid

This was cleaned up as part of HDFS-5255. Thanks for checking. I have resolved 
it.

> Target port chosen by Hftp/Hsftp for getting delegation token may be incorrect
> ------------------------------------------------------------------------------
>
>                 Key: HDFS-5275
>                 URL: https://issues.apache.org/jira/browse/HDFS-5275
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 3.0.0
>            Reporter: Arpit Agarwal
>            Assignee: Haohui Mai
>
> The port selection to get the delegation token is confusing. Also the code 
> documentation and tests appear to conflict.
> The comment in {{HftpFileSystem#getCanonicalServiceName}} seems to indicate 
> that the configured secure port should be chosen, ignoring the port from the 
> URI.
> {code}
>   public String getCanonicalServiceName() {
>     // unlike other filesystems, hftp's service is the secure port, not the
>     // actual port in the uri
>     return SecurityUtil.buildTokenService(nnSecureUri).toString();
>   }
> {code}
> However {{TestHftpFileSystem#testHsftpCustomUriPortWithCustomDefaultPorts}} 
> tests that the returned port is the one from the URI.
> {code}
> @Test
> public void testHsftpCustomUriPortWithCustomDefaultPorts() throws IOException 
> {
>   conf.setInt(DFSConfigKeys.DFS_NAMENODE_HTTPS_PORT_KEY, 456);
>   URI uri = URI.create("hsftp://localhost:789";);
>   HsftpFileSystem fs = (HsftpFileSystem) FileSystem.get(uri, conf);
>   assertEquals(456, fs.getDefaultPort());
>   assertEquals(456, fs.getDefaultSecurePort());
>   assertEquals(uri, fs.getUri());
>   assertEquals(
>       "127.0.0.1:789",
>       fs.getCanonicalServiceName()
>   );
> }
> {code}
> The test still passes because {{HsftpFileSystem}} (incorrectly?) overrides 
> {{getNamenodeSecureAddr}}.
> Either the code needs to be fixed or we should document the correct behavior.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to