In login process Roundcube converts password input to ISO-8859-1 which is wrong because it's not possible to use characters that are not convertable to ISO-8859-1, which of course may be confusing for users. Also user will be not able to use password set via Roundcube password plugin in other client. Another issue would be if someone uses clear text passwords in (unicode) database, postgres will not store text encoded in non-unicode encoding.
My opinion is that in Roundcube login process we should convert password to ASCII and in Password plugin we should make sure that user is using only printable ASCII characters. What do you think?
On Mon, Feb 22, 2010 at 16:04, A.L.E.C alec@alec.pl wrote:
In login process Roundcube converts password input to ISO-8859-1 which is wrong because it's not possible to use characters that are not convertable to ISO-8859-1, which of course may be confusing for users. Also user will be not able to use password set via Roundcube password plugin in other client. Another issue would be if someone uses clear text passwords in (unicode) database, postgres will not store text encoded in non-unicode encoding.
I think it depends on the IMAP backend whether unicode passwords are accepted. The conversion to ISO-Latin was inserted because of some backend problems. For best support we maybe need the admin to specify which backend is used.
My opinion is that in Roundcube login process we should convert password to ASCII and in Password plugin we should make sure that user is using only printable ASCII characters. What do you think?
This only partially solves the problem. Many users already have a password to their IMAP account which can contain non-ascii chars. Therefore it's dangerous just to convert all incoming passwords to ascii.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Thomas Bruederli wrote:
I think it depends on the IMAP backend whether unicode passwords are accepted. The conversion to ISO-Latin was inserted because of some backend problems. For best support we maybe need the admin to specify which backend is used.
My opinion is that in Roundcube login process we should convert password to ASCII and in Password plugin we should make sure that user is using only printable ASCII characters. What do you think?
This only partially solves the problem. Many users already have a password to their IMAP account which can contain non-ascii chars. Therefore it's dangerous just to convert all incoming passwords to ascii.
Yes, that's right, but we need a consistent behavior in password plugin and Roundcube. Imagine a password "żyła" (Polish), it will be converted to "zyla" in latin1. So, currently if I set this password in Roundcube, I will be not able to log in. If I modify password plugin to convert password to latin1 as Roundcube does, I'll able to log in in Roundcube, but probably not in other client until I know what conversion is used. I know, but my users doesn't.
Maybe we should use password "as is" in UTF-8. If someone needs a conversion would use 'authenticate' hook or we'd provide config option 'password_charset'. This would be a regression but we need to do something.
On Tue, Feb 23, 2010 at 13:41, A.L.E.C alec@alec.pl wrote:
This only partially solves the problem. Many users already have a password to their IMAP account which can contain non-ascii chars. Therefore it's dangerous just to convert all incoming passwords to ascii.
Yes, that's right, but we need a consistent behavior in password plugin and Roundcube. Imagine a password "żyła" (Polish), it will be converted to "zyla" in latin1. So, currently if I set this password in Roundcube, I will be not able to log in. If I modify password plugin to convert password to latin1 as Roundcube does, I'll able to log in in Roundcube, but probably not in other client until I know what conversion is used. I know, but my users doesn't.
Yes, you're right. The password plugin should be consistent to the login process of Roundcube.
Maybe we should use password "as is" in UTF-8. If someone needs a conversion would use 'authenticate' hook or we'd provide config option 'password_charset'. This would be a regression but we need to do something.
The 'password_charset' option sounds reasonable to me. It could be used by both index.php and the password plugin and should default to ISO-8859-1 to remain compatible with older versions. Maybe the password plugin also needs some textual explanation which characters are allowed according to the configured 'password_charset' option. Or convert the password entered by the user to whatever charset and back to UTF-8 and then show an error when these two strings do not match. This would mean that the user has entered a password with "invalid" characters.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
-
A.L.E.C -
Thomas Bruederli