[jira] Updated: (FTPSERVER-184) IODataConnection ASCII mode does not work as expected.
[
https://issues.apache.org/jira/browse/FTPSERVER-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Gustavsson updated FTPSERVER-184:
Component/s: Core
Fix Version/s: 1.0-M4
Assignee: Niklas Gustavsson
Affects Version/s: 1.0-M2
1.0-M3
> IODataConnection ASCII mode does not work as expected.
> --
>
> Key: FTPSERVER-184
> URL: https://issues.apache.org/jira/browse/FTPSERVER-184
> Project: FtpServer
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0-M2, 1.0-M3
>Reporter: David Latorre
>Assignee: Niklas Gustavsson
> Fix For: 1.0-M4
>
>
> New lines in files sent in ASCII mode are transformed into /r/n no matter
> what platform the ftp server is running on. But if I'm not wrong, the new
> EOL should be equal to "line.separator" . If ASCII mode is going to be
> supported, this ought to be changed.
>
> The code in IODataConnection.transfer()
> {
> if (isAscii) {
> for (int i = 0; i < count; ++i) {
> byte b = buff[i];
> if (b == '\n' && !lastWasCR) {
> bos.write('\r');
> }
> if (b == '\r') {
> lastWasCR = true;
> } else {
> lastWasCR = false;
> }
> bos.write(b);
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-184) IODataConnection ASCII mode does not work as expected.
IODataConnection ASCII mode does not work as expected.
--
Key: FTPSERVER-184
URL: https://issues.apache.org/jira/browse/FTPSERVER-184
Project: FtpServer
Issue Type: Improvement
Reporter: David Latorre
New lines in files sent in ASCII mode are transformed into /r/n no matter
what platform the ftp server is running on. But if I'm not wrong, the new EOL
should be equal to "line.separator" . If ASCII mode is going to be supported,
this ought to be changed.
The code in IODataConnection.transfer()
{
if (isAscii) {
for (int i = 0; i < count; ++i) {
byte b = buff[i];
if (b == '\n' && !lastWasCR) {
bos.write('\r');
}
if (b == '\r') {
lastWasCR = true;
} else {
lastWasCR = false;
}
bos.write(b);
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-183) DBUserManager and PropertiesUserManager are not storing the password in the User object after in "authenticate()"
[ https://issues.apache.org/jira/browse/FTPSERVER-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-183: Description: 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. was: 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(; I'm providing a patch although maybe there's a more elegant solution. Summary: DBUserManager and PropertiesUserManager are not storing the password in the User object after in "authenticate()" (was: DBUserManager is not storing the password in the User object) > 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.
[jira] Updated: (FTPSERVER-183) DBUserManager and PropertiesUserManager are not storing the password in the User object after in "authenticate()"
[ https://issues.apache.org/jira/browse/FTPSERVER-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-183: Attachment: UserManagers.patch Patch for the NullPointerException issue in DBUserManager - authenticate() will add the unencrypted password to the User object. > 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.
[jira] Created: (FTPSERVER-183) DBUserManager is not storing the password in the User object
DBUserManager is not storing the password in the User object 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 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(; I'm providing a patch although maybe there's a more elegant solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
