[
https://issues.apache.org/jira/browse/HADOOP-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18083991#comment-18083991
]
ASF GitHub Bot commented on HADOOP-19904:
-----------------------------------------
magnuma3 opened a new pull request, #8521:
URL: https://github.com/apache/hadoop/pull/8521
Contains content generated by Claude Opus 4.7
### Description of PR
HADOOP-19904
#### 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
Add a static helper `JettyAuthenticationHelper.publishRemoteUser(...)`
in hadoop-auth that:
1. Reads the effective user (`getRemoteUser()` or an explicit name),
2. Calls `Request.setAuthentication(...)` on the base `Request` with
a minimal inline `Authentication.User` (no `jetty-security`
dependency),
Invocation sites cover the paths where the effective user is decided:
- `AuthenticationFilter.doFilter(filterChain, request, response)` —
the protected hook called after wrapping. Subclasses
(`ProxyUserAuthenticationFilter`, `DelegationTokenAuthenticationFilter`)
wrap with doAs/UGI and route through `super.doFilter`, so this
single hook covers them.
- `DelegationTokenAuthenticationHandler.managementOperation` for
`GETDELEGATIONTOKEN`/`RENEW`/`CANCEL` — the handler writes the
response inline and returns false, skipping the filter chain, so
the helper is called directly there.
- `JspHelper.getUGI` for HDFS Web UI / WebHDFS servlets that resolve
UGI outside the filter chain.
No `HttpServer2` configuration changes required; calls are inline at
each path. Works for both Kerberos and pseudo-auth (both feed the
user through `getRemoteUser()` / `requestUgi`).
### 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: HADOOP-19904
> URL: https://issues.apache.org/jira/browse/HADOOP-19904
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: KWON BYUNGCHANG
> Priority: Major
> Labels: pull-request-available
>
> 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]
