Timo Sirainen wrote:
On Thu, 2008-08-21 at 09:11 +0200, Tom Sommer wrote:
Timo Sirainen wrote:
On Tue, 2008-08-19 at 15:49 +0200, Tom Sommer wrote:
On Tue, August 19, 2008 15:44, Tom Sommer wrote:
Using version 1.1.1, MySQL userdb, with "nopassword=Y".
Maybe it's due to nopassword?
Should add, this is my password_query:
password_query = SELECT username as user, NULL as password, "Y" as nopassword FROM users WHERE ...
So how do you check the password validity?
Simple
SELECT username as user, NULL as password, "Y" as nopassword FROM users WHERE username = '%u' AND password = '[password]'
By [password] I suppose you mean %w?
The way it's supposed to work then is that Dovecot places %u and %w to the cache key. So only if both of them match, the cache is used. This also means that if the password is changed and old password is cached, the user is able to log in using either old or the new password (both of them will be cached to separate entries). And I just tested that it works like that. So if you're getting auth failures, there's something wrong.
Sorry to bump this, but I can still reproduce it - I have enabled auth_debug now to attempt to provide some more details.
It seems to happen after some time have passed, so maybe it has something to do with auth_cache_size being reached, some incremented ID growing too large and wrapping? or.. well, I don't know, and I don't know enough C++ to be smart on the code :) As I wrote previously, a simple restart of Dovecot fixes the problem for a while.
It also seem to only happen if both the new and the old password is entirely numeric and 8 ciphers.
Will get back with more details when I have a case where auth_debug was enabled.
Any help is appreciated, thanks.
Tom Sommer