Hi again, I finally found the time and got my arms around the idea of drivers as in Horde. So I did some very limited prototyping with the current CVS version of web-cyradm to try to demonstrate the concept. I will attach a little tar archive that is to be extracted to the web-cyram directory.
The only thing that works for now is the _static driver which will always reply "true" to the _check method. The _ldap driver is just a skeleton for now. In case we like the concept and want to go further down that road, then I would probably have to move anything which is the crypto.php file into a _sql driver, right? If the final goal was to eliminate the need for an SQL database at all, there will be more changes necessary. Right now for example when browsing accounts the code to query an SQL database for all existing accounts is built right into the user interface code. I think in the longer run we will also need a sort of driver concept here where we have drivers that will either query - an SQL database (today's code) - the LDAP server - the mail server itself Regarding the latest two, I wonder anyway what the best approach would be. This isn't really a web-cyradm question but more an issue of general interest: How can we make sure that the mailbox names and the LDAP / SQL user entries are kept in sync. For example, if you login to the cyrus imapd from the command line and delete a mailbox, web-cyradm will still think it's there, won't it? As a near term goal, what I will have a look at (given there are no major comments on the approach taken) will be: - finish the auth stuff - triggering LDAP operations in parallel to the SQL operations What I mean is: If a new mailbox is created in web-cyradm, the existing code will (I assume) - create a mailbox in cyrus imapd (cm ...) - create an entry in the SQL database for the user So it should not be that difficult to add a line of code that calls a mechanism that will also make / alter a corresponding LDAP entry. This makes me think of implementing a PAM concept where any providers can register and web-cyradm will just cycle through the list and call each of them. Any thoughts? Anyone has any experience with this? Reagards, Torsten > --- Urspr�ngliche Nachricht --- > Von: "Torsten Schlabach" <[EMAIL PROTECTED]> > An: [email protected] > Betreff: Re: [Web-cyradm] LDAP ... any preferences? > Datum: Tue, 12 Apr 2005 16:30:35 +0200 (MEST) > > Luc, > > > >>Hmm... I wonder what is the best idea. It is needed to abstract the > > >>whole authentication and authorization stuff. So maybe something > > >>horde-like with drivers can be a solution? > > > > > > > > > Can you give any pointers to that concept? I was unable to access > > > http://www.horde.org/ today (HTTP 500 - Internal Server error). > > > > You can choose different datasources for different purposes. Best place > > to look at it is in /horde/config. BTW: horde.org went back online... > > I found some good reading here: > > http://www.horde.org/papers/oscon2002hordeconf.pdf > > (Also for the benefit of everyone else on the list.) > > My understanding than would be that we'd have to gradually introduce some > more OO concepts into web-cyradm. If I get the concept of drivers in Horde > right, then I would compare a driver to an Interface in Java, right? > > I mean the plan is to define a number of methods that any object which > connects to a back-end needs to understand. The driver basically decides > which implementation of the interface (which class) is to be used, right? > > To take complexity to the next level, I am not sure if we would need to > choose different data stores for different items or at least offer a > choice > here. I think it will heavily depend on a particular setup, but depending > on > a specific environment, you can either store any information that > web-cyradm > needs into the same backend or you cannot. > > If you cannot, you will need an auxilliary storage. > > This topic is getting more and more complex ... but also interesting. > > I will see how far I can get with prototyping some stuff for the password > auth in the first place. I think this will show what questions arise for > the > rest. > > Regards, > Torsten > > > Torsten Schlabach wrote: > > > Luc, > > > > > > > > >>>1. Should we use the PHP LDAP functions > > >>>(http://www.php.net/manual/en/ref.ldap.php) or rather PEAR::Net:LDAP > or > > >>>PEAR::ldap or PEAR::ldap2? > > >> > > >>I have no preferences, what is your opinion? Pros? Contras? > > > > > > > > > This makes a difference especially for people who don't have full > > control of > > > their environment. If you want to use the PHP LDAP functions (i.e. > > ldap_...) > > > they needs to be enabled in the PHP binary that web-cyradm is supposed > > to > > > run on. If it isn't, this means you have to re-compile your PHP to > make > > it > > > run. If this is an option at all. (I am thinking of hosted > environments, > > > though I am not sure if ISPs will allow you to install custom PEAR > > modules. > > > Never had that problem.) > > > > If the PEAR::ldap classes does not need ldap support compiled in PHP > > then we should definitely go for PEAR. > > > > > > > > I also think that there should be a consistent direction used > throughout > > > web-cyradm. For example, when it comes to database access, you've > > choosen > > > the PEAR:DB stuff, not the PHP built-in MySQL functions. You also > don't > > rely > > > on the built-in functions to interface the Cyrus IMAPd, though there > > would > > > be even two different sets of functions to choose from. So I think it > > would > > > make most sense in this context to go for the PEAR stuff also for LDAP > > > access. > > > > There have been several good reasons for it. PEAR::DB provides DB > > abstraction, so web-cyradm is supporting MySQL and POstgreSQL (only > > limited by pam_you-name-it-database and availability of patches for > > postfix. > > > > In 2001 the cyrus stuff of PHP was simply not working. > > > > I agree with the PEAR ldap access (see above) > > > > > > > > I have seen there are LDAP drivers for PEAR:DB. But I doubt they will > do > > the > > > trick in a way that the code does not need any major modifications in > > oder > > > to support LDAP but just by replacing the driver, unfortunately. > Though > > it > > > might be worth looking at. > > > > This would simplify the work much, I'll having a look at it. > > > > > > > > > > >>Hmm... I wonder what is the best idea. It is needed to abstract the > > >>whole authentication and authorization stuff. So maybe something > > >>horde-like with drivers can be a solution? > > > > > > > > > Can you give any pointers to that concept? I was unable to access > > > http://www.horde.org/ today (HTTP 500 - Internal Server error). > > > > You can choose different datasources for different purposes. Best place > > to look at it is in /horde/config. BTW: horde.org went back online... > > > > > > > > It's question how far you intend to take OO in web-cyradm. If you plan > > to > > > make a strong move towards OO concepts I'd agree with you that neither > > of my > > > suggestions would be a perfect solution. > > > > > > Then again, PHP has changed a lot when it comes to OO with the 5.x > > releases. > > > Should web-cyradm depend on 5.x so it will be safe to use these > features > > or > > > will there be a need to stay backwards-compatible with earlier PHP > > releases. > > > If yes, how far? Is there any official statement somewhere regarding > > > web-cyradm's requirements to PHP? > > > > The official Statement is: Web-cyradm should work with PHP 4.3.x and > > above (inluding 5.0.x) > > > > This limits the OO code to be realized, but for the next two years I > > think it is important to also support PHP 4.3 because a lot of people > > are and will be stuck at PHP 4 for the next time (i.e all with are using > > typo3 with older extensions) > > > > > P.S.: You might want to update the web-cyradm website to reflect the > > fact > > > that the mailing list is back online! > > > > Thanks for the reminder, its done :-) > > > > rgds > > > > Luc > > _______________________________________________ > > This mailing list is hosted and supported > > by bit-heads GmbH | http://www.bit-heads.ch > > > > _______________________________________________ > > Web-cyradm mailing list > > [email protected] > > http://www.web-cyradm.org/mailman/listinfo/web-cyradm > > > _______________________________________________ > This mailing list is hosted and supported > by bit-heads GmbH | http://www.bit-heads.ch > > _______________________________________________ > Web-cyradm mailing list > [email protected] > http://www.web-cyradm.org/mailman/listinfo/web-cyradm > _______________________________________________ This mailing list is hosted and supported by bit-heads GmbH | http://www.bit-heads.ch _______________________________________________ Web-cyradm mailing list [email protected] http://www.web-cyradm.org/mailman/listinfo/web-cyradm
