Here's another idea that builds upon this, with fewer changes... since I can think of at least one potential auth mechanism that won't work well with aliases - PAM - and so perhaps we should do a combination effort:
Each db implements the alias function as db_...alias... All calls to the ...alias... function MUST be to auth_...alias... and unless the auth mechanism can provide its own aliasing, just pass along the call to the underlying db_...alias... function. In this way, an auth module could also use both its own aliases and aliases from the database to create a more configurable environment. Or maybe it's just needless complexity, and I'm scratching my head hoping that someone is listening and thinking about alternative auth's... Aaron On Tue, 7 Jan 2003, Aaron Stone wrote: > Hi, > > As I get further along on the LDAP auth module, I've noticed that the > alias table functions are all in the db.h and not in the auth.h > abstraction. Since the "native LDAP" posixAccount and MS's Active > Directory "user" classes both include the possibility for multiple mail > and mailAlternate attributes, it makes sense to use these fields as the > aliases for the given account. > > Perhaps we could move these functions into auth.h... > > u64_t db_get_user_from_alias(const char *alias); > char* db_get_deliver_from_alias(const char *alias); > > int db_get_user_aliases(u64_t userid, struct list *aliases); > int db_addalias(u64_t useridnr, char *alias, u64_t clientid); > int db_addalias_ext(char *alias, char *deliver_to, u64_t clientid); > int db_removealias(u64_t useridnr, const char *alias); > int db_removealias_ext(const char *alias, const char *deliver_to); > > > Aaron > > _______________________________________________ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail >
