[Dovecot] password_query, user_query and unrelated userid and emails
Let's say one has a SQL table with following fields for John Doe:
login: u0007
password: {SHA1}...
mailhome: /path/to/joeshome
email: john.doe@example.com
To log in, for internal policy reasons, John MUST make use of his userid "u0007". So, in the password_query, one would need something like:
... WHERE login = '%u' ...
On the other hand, for receiving mail thru say, LMTP, one would need something like this in the user_query:
... WHERE email = '%Lu' ...
With such a simplistic setup, this works fine:
$ doveadm auth u0007
Password:
passdb: u0007 auth succeeded
but this one obviously fails:
$ doveadm user u0007
userdb lookup: user u0007 doesn't exist
and one has to do:
$ doveadm user john.doe@example.com
userdb: john.doe@example.com
home : /path/to/joeshome
I can't manage to devise a way to systematically refer to users thru their login, nor to avoid such messages:
prefetch(u0007): passdb didn't return userd entries, trying the next userdb
There sure must be a way thru adequate "SELECT ... AS ..." clauses. Could someone show me the light?
Many, many TIA, Axel
On Sat, 2010-09-25 at 15:23 +0200, Axel Luttgens wrote:
Let's say one has a SQL table with following fields for John Doe:
login: u0007 password: {SHA1}... mailhome: /path/to/joeshome email: john.doe@example.com
To log in, for internal policy reasons, John MUST make use of his userid "u0007". So, in the password_query, one would need something like:
... WHERE login = '%u' ...
On the other hand, for receiving mail thru say, LMTP, one would need something like this in the user_query:
... WHERE email = '%Lu' ...
You could make it so that password_query changes the username to email by selecting "email AS user" and then user_query has only the email='% Lu'. Or you could make your user_query have "where (email='%Lu' or user='%u').
I can't manage to devise a way to systematically refer to users thru their login, nor to avoid such messages:
prefetch(u0007): passdb didn't return userd entries, trying the next userdb
This seems like a different problem to me..
participants (2)
-
Axel Luttgens
-
Timo Sirainen