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/