[jira] Commented: (FTPSERVER-183) DBUserManager and PropertiesUserManager are not storing the password in the User object after in "authenticate()"

2008-10-31 Thread Niklas Gustavsson (JIRA)

[ 
https://issues.apache.org/jira/browse/FTPSERVER-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644320#action_12644320
 ] 

Niklas Gustavsson commented on FTPSERVER-183:
-

Yeah, this is an odd area. The reason for the current code is that if the 
UserManager would populate the password, that might be encrypted. And, if you 
would call save() on that user, the password would encrypted again... no good. 
So, what we do is that if the password is provided on the User, we do 
store/update it. Otherwise, we don't. This is handled correctly in 
PropertiesUsermanager, but not in DbUserManager. I'll fix that.

> DBUserManager and PropertiesUserManager are not storing the password in the 
> User object after in "authenticate()" 
> --
>
> Key: FTPSERVER-183
> URL: https://issues.apache.org/jira/browse/FTPSERVER-183
> Project: FtpServer
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0-M4
>Reporter: David Latorre
>Assignee: Niklas Gustavsson
>Priority: Minor
> Fix For: 1.0-M4
>
> Attachments: UserManagers.patch
>
>
> I suppose that as a result of the change in the strategy to encrypt passwords 
> in DBUserManager, getUserByName()  -called by the authenticate() method - 
> returns an User object with the password field unset.
> When trying to use the "save" method , this line throws  a 
> NullPointerException
>   map.put(ATTR_PASSWORD, 
> escapeString(passwordEncryptor.encrypt(user.getPassword(;
> My reason to use this method is that I call  DBUserManager.save() to update 
> the user in the database with last-login information. 
> I'm providing a patch although maybe there's a more elegant solution.   The 
> same modification is done in PropertiesUserManager for coherence.
> Important Note: with my provided path , the user's password should not be 
> included in the WHERE query of "updateStatement" as there's a chance that for 
> a  PasswordEncryptor, the result of   passwordEncryptor.encrypt  is not the 
> same as the stored password even if matches() returns true.
>  
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (FTPSERVER-183) DBUserManager and PropertiesUserManager are not storing the password in the User object after in "authenticate()"

2008-09-30 Thread David Latorre (JIRA)

[ 
https://issues.apache.org/jira/browse/FTPSERVER-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635691#action_12635691
 ] 

David Latorre commented on FTPSERVER-183:
-

Niklas, 

 Did you notice this issue? Is there any problem with my solution or some other 
problems you're foreseeing?




> DBUserManager and PropertiesUserManager are not storing the password in the 
> User object after in "authenticate()" 
> --
>
> Key: FTPSERVER-183
> URL: https://issues.apache.org/jira/browse/FTPSERVER-183
> Project: FtpServer
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0-M4
>Reporter: David Latorre
>Priority: Minor
> Attachments: UserManagers.patch
>
>
> I suppose that as a result of the change in the strategy to encrypt passwords 
> in DBUserManager, getUserByName()  -called by the authenticate() method - 
> returns an User object with the password field unset.
> When trying to use the "save" method , this line throws  a 
> NullPointerException
>   map.put(ATTR_PASSWORD, 
> escapeString(passwordEncryptor.encrypt(user.getPassword(;
> My reason to use this method is that I call  DBUserManager.save() to update 
> the user in the database with last-login information. 
> I'm providing a patch although maybe there's a more elegant solution.   The 
> same modification is done in PropertiesUserManager for coherence.
> Important Note: with my provided path , the user's password should not be 
> included in the WHERE query of "updateStatement" as there's a chance that for 
> a  PasswordEncryptor, the result of   passwordEncryptor.encrypt  is not the 
> same as the stored password even if matches() returns true.
>  
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.