Ralph Goers wrote at Freitag, 14. August 2009 01:44: > > On Aug 13, 2009, at 4:18 PM, Jörg Schaible wrote: > >> Ralph, >> >> >> is this transparent for a UserAuthenticator ? >> > > I don't believe it applies to UserAuthenticators at all. When a > userid and password are placed in a url the url eventually gets parsed > to create a FileName. During the creation of the FileName the password > is decrypted. When the various FileSystems set up for authentication > they call > > authData = UserAuthenticatorUtils.authenticate(fileSystemOptions, > AUTHENTICATOR_TYPES); > > and then > > UserAuthenticatorUtils > .toString(UserAuthenticatorUtils.getData(authData, > UserAuthenticationData.PASSWORD, > UserAuthenticatorUtils.toChar(rootName.getPassword()))) > > If a UserAuthenticator is not present in the FileSystemOptions then > authData will be null. The call to UserAuthenticatorUtils.getData will > then use the default value which is the password in the FileName. > > If a UserAuthenticator is present the password set in it will be used > and the value in the url will be ignored. > > Having said that, StaticUserAuthenticator seems to be the only > implementation in VFS and I can't find any tests that use it so there > is no way to verify that UserAuthenticators even work.
It works ... :) ... the lack of any test is unfortunate though. To support encryption in the StaticUserAuthenticator, the algorithm to decrypt it could be applied at the password provided in the constructor. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
