I'm working on a new setup where we would like to used stored procedures
for an
extra layer of security, in addition to having a where-clause to limit
who can use
a perdition-server.
Has anyone made any patches to perdition / perditiondb_mysql to allow
for either
of these scenarios?
Examples:
1) Use a stored procedure to return a result instead of giving the
perdition mysql user
access to the whole database.
If I would have a table called "users" with the fields "email" and
"mailserver" I could map
these into perdition expected fields
CREATE PROCEDURE perdition_lookup (parameter_user VARCHAR(128))
BEGIN
SELECT email AS user, mailserver AS servername FROM users WHERE email
= parameter_user LIMIT 1
END;
Then perdition_mysql could be set up with CALL perdition_lookup(\U) or
something similar.
2) We will use multiple perdition servers and only some users should be
allowed to use
one of the servers (while all of them are allowed to use the second
one).
The addition of a WHERE-clause in the configuration would help make this
possible.
Example:
map_library_opt
dbserver:3306:dbPerdition:tblPerdition:perdition:perditionpassword:mailserver:email:NULL:SomeExtraField='Y'
Or for full flexibility allow overriding of the query like postfix or
dovecot:
# Perdition expects the fields "user", "servername" and "port" to be
retured by the query. %u will be substituted
# for what the user provided as login information
map_library_query SELECT email AS user, mailserver AS servername, NULL
as port FROM users WHERE email = '%u' AND SomeExtraField='Y'
As an alternative, could I cheat with using query_key?
query_key \U-Y
map_library_opt
dbserver:3306:dbPerdition:tblPerdition:perdition:perditionpassword:mailserver:CONCAT(email,'-',SomeExtraField):NULL
--
Harald
