[ 
https://issues.apache.org/jira/browse/HDFS-16129?focusedWorklogId=633619&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-633619
 ]

ASF GitHub Bot logged work on HDFS-16129:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 04/Aug/21 14:55
            Start Date: 04/Aug/21 14:55
    Worklog Time Spent: 10m 
      Work Description: tomicooler commented on a change in pull request #3209:
URL: https://github.com/apache/hadoop/pull/3209#discussion_r682695204



##########
File path: 
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/http/HttpServer2.java
##########
@@ -811,18 +822,25 @@ private static SignerSecretProvider 
constructSecretProvider(final Builder b,
       throws Exception {
     final Configuration conf = b.conf;
     Properties config = getFilterProperties(conf,
-                                            b.authFilterConfigurationPrefix);
+        b.authFilterConfigurationPrefixes);
     return AuthenticationFilter.constructSecretProvider(
         ctx, config, b.disallowFallbackToRandomSignerSecretProvider);
   }
 
-  private static Properties getFilterProperties(Configuration conf, String
-      prefix) {
-    Properties prop = new Properties();
-    Map<String, String> filterConfig = AuthenticationFilterInitializer
-        .getFilterConfigMap(conf, prefix);
-    prop.putAll(filterConfig);
-    return prop;
+  public static Properties getFilterProperties(final Configuration conf, final 
List<String> prefixes) {

Review comment:
       Ok, I'll change it back and remove the finals from the inner lines too, 
it is quite short anyway. 
   
   I read some debates on this topic, if final is used consistently then the 
ones without final will catch your eyes more easily. (e.g.: 
http://www.javapractices.com/topic/TopicAction.do?Id=23)




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Issue Time Tracking
-------------------

    Worklog Id:     (was: 633619)
    Time Spent: 5h 50m  (was: 5h 40m)

> HttpFS signature secret file misusage
> -------------------------------------
>
>                 Key: HDFS-16129
>                 URL: https://issues.apache.org/jira/browse/HDFS-16129
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: httpfs
>    Affects Versions: 3.4.0
>            Reporter: Tamas Domok
>            Assignee: Tamas Domok
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 5h 50m
>  Remaining Estimate: 0h
>
> I started to work on the YARN-10814 issue, and found this bug in the HttpFS. 
> I investigated the problem and I already have some fix for it.
>  
> If the deprecated *httpfs.authentication.signature.secret.file* is not set in 
> the configuration (e.g.: httpfs-site.xml) then the new 
> *hadoop.http.authentication.signature.secret.file* config option won't be 
> used, it will fallback to the random secret provider silently.
> The _HttpFSServerWebServer_ sets an _authFilterConfigurationPrefix_ when 
> building the server for the old path (*httpfs.authentication.*). Later the 
> _AuthenticationFilter.constructSecretProvider_ will immediately fallback to 
> +random+, because the config won't contain the file. If the old path was set 
> too, then it handled the file, and the provider was set to +file+ type.
> The configuration should be based on both the old and the new prefix filter, 
> merging the two. The new config option should win in my opinion.
>  
> There is another issue in the _HttpFSAuthenticationFilter_, it is closely 
> related.
> If both config option is set then the _HttpFSAuthenticationFilter_ will fail 
> with an impossible file path (e.g.: 
> *${httpfs.config.dir}/httpfs-signature.secret*).
> _HttpFSAuthenticationFilter_ constructs the configuration, filtering first 
> the new config prefix then the old prefix. The old prefix code works 
> correctly, it uses the _conf.get(key)_
> instead of the _entry.getValue()_ which gives back the file path mentioned 
> earlier. The code duplication can be eliminated and I think it would be 
> better to change the order, first adding the config options from the old path 
> then the new, and the new should overwrite the old values, with a warning log 
> message.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to