On Tue, Aug 19, 2008 at 1:50 PM, David Latorre <[EMAIL PROTECTED]> wrote: > Hey Niklas, > > As you have said, encryption should probably be called from the > UserManager. That's why I extended DBUserManager in order to perform > encryption in the Incubator version of FTPServer. > I could use that same user manager in this version but I found that I could > not take advantage of the XSD definition of <db-user-manger> (what about > using getBeanClassName() rather than getBeanClass() in the > BeanDefinitionParsers() and adding an optional "class" attribute in the > elements where it makes sense? )
Yes, I did consider that. However, I went with the option of keeping the XML config as simple as possible, while deferring to the bean:bean element in the case where extensions are needed. But, maybe I should reconsider. > and then I thought, hey it would be cool that the UserManager delegated > password encryption to an external bean configured via Spring ... this way > It would be possible to plug in any 'password-processing' mechanism into > any User Manager without a need to change the User Manager itself. I like the idea of delegating it to a different bean, not sure if I think that strategy needs to be configurable as a Spring bean. > Although the option of calling an "encryptPassword" function inside the > UserManager should be enough, I think I've seen the bean implementing a > method approach quite often (eg, i think there is such a method to verify a > digital certificate in JBOSS). How about we do a common password encryption strategy between PropertiesUserManager and DbUserManager? Right now, PropertiesUserManager does a simple MD5 on the password, but this is not a good idea as it is not secure against lookup attacks. So, I'm planning to rewrite it to use a stronger hashing algorithm (salt and multiple hashing rounds). At the same time, it might make sense to do the same for DbUserManager. Would that solve your issue? /niklas
