[
https://issues.apache.org/jira/browse/VFS-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18062764#comment-18062764
]
Vlad Skarzhevskyy edited comment on VFS-861 at 3/4/26 4:26 PM:
---------------------------------------------------------------
Gary Thanks for the quick response..
Unfortunately, authentication is now *broken for Http4FileProvider* and
{*}still broken for Http5FileProvider{*}.
We verified this both with the minimal reproduction project and in our product
integration tests.
- in first commit bafb54b49db0cfa9c163fce03f28ff3d09742bb6 '[[VFS-861]
Http5FileProvider Basic authentication
fails:|https://github.com/apache/commons-vfs/commit/bafb54b49db0cfa9c163fce03f28ff3d09742bb6]
the Http5FileProvider the auth still borken..
- after other changes (master branch) auth borken for Http4 provider as well
was (Author: vlads):
Gary Thanks for the quick response..
Unfortunately, authentication is now *broken for Http4FileProvider* and
{*}still broken for Http5FileProvider{*}.
We verified this both with the minimal reproduction project and in our product
integration tests.
- in first commit bafb54b49db0cfa9c163fce03f28ff3d09742bb6 '[[VFS-861]
Http5FileProvider Basic authentication
fails:|https://github.com/apache/commons-vfs/commit/bafb54b49db0cfa9c163fce03f28ff3d09742bb6]
the Http5FileProvider the auth still borken..
*-* after other changes (master branch) auth borken for Http4 provider as well
**
> Http5FileProvider Basic authentication fails:
> UserAuthenticationData.setData(Type, char[]) should clone its array input
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: VFS-861
> URL: https://issues.apache.org/jira/browse/VFS-861
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.10.0
> Reporter: Vaishnavi Kumbhar
> Assignee: Gary D. Gregory
> Priority: Major
> Fix For: 2.11.0
>
>
> h2. Title
> Http5FileProvider Basic authentication fails: password in credentials is
> wiped by UserAuthenticatorUtils.cleanup(authData)
> h2. Description
> We discovered authentication problem when migrating our application from
> deprecated Http4FileProvider to Http5FileProvider.
> *Our analysis of the problem:* In
> {{{}Http5FileProvider.createHttpClientContext(){}}}, the password is passed
> to {{UsernamePasswordCredentials}} as the *same {{char[]}}* reference
> returned from {{{}UserAuthenticatorUtils.getData(authData, PASSWORD,
> ...){}}}. In {{{}doCreateFileSystem(){}}},
> {{UserAuthenticatorUtils.cleanup(authData)}} is called in a {{finally}} block
> to clear sensitive data. That method zeros the character arrays inside
> {{{}authData{}}}. Because the credentials object holds a *reference* to the
> same array, the password in the credentials is also zeroed *before* any HTTP
> request is made. Http4 does not have this bug because it uses
> {{{}UserAuthenticatorUtils.toString(getData(...)){}}}, which creates a *new
> String* (a copy), so the credentials keep their own data.
> h2. Steps to reproduce
> # Clone the minimal reproduction project:
> ([https://github.com/VaishKumbhar/vfs2-issue])
> # Run: {{mvn test}}
> # Observe: test {{http4WithBasicAuthSucceeds}} passes; test
> {{http5WithBasicAuthFailsBecausePasswordWipedByCleanup}} fails with Http5
> does *not* return the protected content (auth failed).
> The project contains:
> * A minimal HTTP server with Basic auth (JDK {{{}HttpServer{}}}, no extra
> deps).
> * VFS2 {{FileSystemManager}} with either Http4 or Http5 provider.
> * {{FileSystemOptions}} with {{StaticUserAuthenticator}} (username/password).
> * Resolve a {{[http://]...}} URL and read content; with Http5 the password
> is already wiped so the request is sent without Authorization.
> h2. Expected behavior
> Http5FileProvider should authenticate successfully, same as Http4FileProvider.
> h2. Actual behavior
> Server returns 401.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
