[ 
https://issues.apache.org/jira/browse/HDFS-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18083696#comment-18083696
 ] 

ASF GitHub Bot commented on HDFS-17928:
---------------------------------------

magnuma3 opened a new pull request, #8519:
URL: https://github.com/apache/hadoop/pull/8519

   Contains content generated by Claude Opus 4.7
   
   <!--
     Thanks for sending a pull request!
       1. If this is your first time, please read our contributor guidelines: 
https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute
       2. Make sure your PR title starts with JIRA issue id, e.g., 
'HADOOP-17799. Your PR title ...'.
   -->
   
   ### Description of PR
   
   HDFS-17928
   
   #### Problem
   HttpServer2's access log always records `-` in the `%u` position even
   for authenticated requests:
   Affects every HttpServer2-backed daemon (NN/DN/RM/NM/HttpFS/KMS).
    
   #### Root cause
   `AuthenticationFilter` wraps `HttpServletRequest` so downstream
   filters and servlets see the user via `getRemoteUser()`. The wrap
   only flows through the filter chain. Jetty's `RequestLogHandler`
   runs outside the chain on the base `Request`, whose
   `getAuthentication()` stays as `NOT_CHECKED` forever.
    
   Jetty's native auth path (`jetty-security` Authenticators) sets
   `Request.setAuthentication(...)` directly, which is why standard
   deployments don't have this issue. Hadoop avoids `jetty-security`
   for container portability and pays this cost.
    
   #### Fix
   Install a small Servlet `Filter` (in hadoop-common) after the
   auth filters that:
    
   1. Reads `getRemoteUser()` from the wrapped request,
   2. Calls `Request.setAuthentication(...)` on the base `Request`
   with a minimal inline `Authentication.User` (no
   `jetty-security` dependency).
    
   `HttpServer2.initializeWebServer` installs it automatically after
   `FilterInitializer`s; no configuration needed. Works for both
   Kerberos and pseudo-auth — both feed the user through
   `getRemoteUser()`.
    
   #### Known gap
   `DelegationTokenAuthenticationHandler.managementOperation` writes
   its response inline and returns `false`, so `AuthenticationFilter`
   skips `filterChain.doFilter`. The bridge filter doesn't run for
   token mgmt requests; the handler attaches directly there.
   
   
   ### How was this patch tested?
   
   Added unit tests and verified on an internal cluster
   
   ### For code changes:
   
   - [x] Does the title or this PR starts with the corresponding JIRA issue id 
(e.g. 'HADOOP-17799. Your PR title ...')?
   - [ ] Object storage: have the integration tests been executed and the 
endpoint declared according to the connector-specific documentation?
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   - [ ] If applicable, have you updated the `LICENSE`, `LICENSE-binary`, 
`NOTICE-binary` files?
   
   ### AI Tooling
   
   If an AI tool was used:
   
   - [x] The PR includes the phrase "Contains content generated by <tool>"
         where <tool> is the name of the AI tool used.
   - [x] My use of AI contributions follows the ASF legal policy
         https://www.apache.org/legal/generative-tooling.html




> HttpServer2 access log does not record the authenticated user
> -------------------------------------------------------------
>
>                 Key: HDFS-17928
>                 URL: https://issues.apache.org/jira/browse/HDFS-17928
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: KWON BYUNGCHANG
>            Priority: Major
>
> h2. Problem
> HttpServer2's access log always records `-` in the `%u` position even
> for authenticated requests:
> Affects every HttpServer2-backed daemon (NN/DN/RM/NM/HttpFS/KMS).
>  
> h2. Root cause
> `AuthenticationFilter` wraps `HttpServletRequest` so downstream
> filters and servlets see the user via `getRemoteUser()`. The wrap
> only flows through the filter chain. Jetty's `RequestLogHandler`
> runs outside the chain on the base `Request`, whose
> `getAuthentication()` stays as `NOT_CHECKED` forever.
>  
> Jetty's native auth path (`jetty-security` Authenticators) sets
> `Request.setAuthentication(...)` directly, which is why standard
> deployments don't have this issue. Hadoop avoids `jetty-security`
> for container portability and pays this cost.
>  
> h2. Fix
> Install a small Servlet `Filter` (in hadoop-common) after the
> auth filters that:
>  
> 1. Reads `getRemoteUser()` from the wrapped request,
> 2. Calls `Request.setAuthentication(...)` on the base `Request`
> with a minimal inline `Authentication.User` (no
> `jetty-security` dependency).
>  
> `HttpServer2.initializeWebServer` installs it automatically after
> `FilterInitializer`s; no configuration needed. Works for both
> Kerberos and pseudo-auth — both feed the user through
> `getRemoteUser()`.
>  
> h2. Known gap
> `DelegationTokenAuthenticationHandler.managementOperation` writes
> its response inline and returns `false`, so `AuthenticationFilter`
> skips `filterChain.doFilter`. The bridge filter doesn't run for
> token mgmt requests; the handler attaches directly there.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

Reply via email to