Paul J Stevens wrote:
I'm digging into this as we speak. The whole auth layer is not really
about authentication at all, or at least not *just* about
authentication. It's too bloated for that. Calling it dbmailUser, or
something alike, would probably cover it better.... Actually, some
kind of UML redesign would really help cleanup the code base
(_ic_fetch, aarrrgh) and provide a better handle for developing
modules such as this. I know Dan was blasted for suggesting this, but
I happen to agree with him on this one. Dbmail is *not* too small for
well formed design patterns.
I don't really know if UML would be the right tool for the job, but some
more formal modelling would be helpful indeed. One thing I've been
thinking about is producing some graphics on how different parts of
DBMail work together etc.
Another thing: We need to get rid of all those +100 lines functions..
They are a PITA if you want to read and/or change anything in them.
The nitty gritty:
All the db_..._quotum_used/all functions should probably stay where
they are. Quota usage should be handled by db.c, with calls from the
auth layer.
However, the auth layer should call a db_something function to check
the existence of a userid/user_idnr in the dbmail_users table, and if
necessary insert a template user record to be used as a cache. We
should probably make sure upon checking that for such a user no
password is defined to prevent overwriting users defined earlier using
authsql. Or maybe dbmail should simply bail-out at all levels if users
exists with passwords to prevent conflicts from differently configured
builds connecting to the same database. We most likely don't want
that, right?
Yup. We don't want different instances confusing eachother.
Records like the DBMAIL_DELIVERY_USERNAME should exist in the sql
tables only, right? I don't see the point of having such a user exist
in the ldap database.
Spot on.
db_get_users_from_clientid
db_get_deliver_from_alias
db_add_alias
db_add_alias_ext
db_remove_alias
db_remove_alias_ext
These can all be renamed and moved to auth/.. quite straightforwardly.
Of course they require reimplementation in the ldap layer.
I agree with your suggestion about delaying this for the 2.1.x
development series (assuming we assume linux kernel style numbering
from now on...)
Unless Aaron (our most experienced ldap developer it seems) puts his
weight behind this, I don't see us finishing this any time real soon.
Even though I'm aching for ldap support :-(
We have a need for LDAP in the neartime future as well, so it's high
priority work for us as well.
Ilja
Ilja Booij wrote:
Aaron Stone wrote:
Ilja Booij <[EMAIL PROTECTED]> said:
I'd like to release 2.0rc8 (yes, flawed release engineering etc, no
need to discuss that right now I think) tomorrow, August 17th (at
about 4pm CET(=3pm GMT)). I'm not aware of any issues that should
be resolved at the moment. am I correct? Please correct me if I'm
wrong.
Sounds good! Main things in this release:
- All new command line switches
- PID files for all daemons
- Database prefixes
- Misc. bugfixes
Things still broken:
- users table and LDAP integration
So RC8 will be about making sure that the new stuff works, and RC9
will be
about making sure that LDAP works. Does that sound right? Anything
else to
test?
I'm wondering about the amount of work that needs to go into making
LDAP authentication work. Can someone (Aaron, Paul) give an
indication about it. I'll try to get up to speed on LDAP programming
ASAP. Can somebody point me to some good tutorials/manuals on the web?
Thanks,
Ilja
--
Ilja Booij
IC&S B.V.
Stadhouderslaan 57
3583 JD Utrecht
www.ic-s.nl
T algemeen: 030 6355730
T direct: 030 6355739
F: 030 6355731
E: [EMAIL PROTECTED]
