19.11.2008 10:27, Geert Hendrickx wrote:
On Wed, Nov 19, 2008 at 08:44:21AM +0200, Fredrik Grönqvist wrote:
Yes, I agree that it should be in UTF-8. My specific problem is that about 80% (a rough estimate) of our users are on either Windows or webmail. Those having passwords containing umlauts etc can log on, using their current client, if the passwords are kept ISO-8859-1 encoded instead of UTF-8.
As Timo pointed out, the options to "fix" this on the server side are currently quite limited, so it seems I have to stick to the lowest common denominator in our password policy.
If you only have to support two or three different charsets, I think you could use a clever MySQL passdb query to match either of them.
Have a look at http://wiki.dovecot.org/AuthDatabase/SQL under "Password verification by SQL server", and expand the password match to something like (passwd = PASSWORD('%w') OR passwd = PASSWORD(CONVERT(_latin1'%w' USING utf8))) assuming you store the passwords as UTF-8 and assume the input is either UTF-8 or ISO-8859-1.
Geert
Thanks for the info, a setup like this is what I opted for eventually. I added a note to that wiki page that the query also needs to return the "nopassword" -field for Dovecot 1.1+ to accept the NULL password:
# NOTE: '\' line splitting is used only for readability, currently Dovecot doesn't support it password_query = SELECT NULL AS password, 'nopassword', userid AS user
FROM users WHERE userid = '%u' AND mysql_pass = password('%w')
In case someone else is looking for info about this, this workaround works for DB backed accounts, as you mention, but will probably not work with an LDAP (or other) backend.