The attachment was missing ... hope it makes it through the list ... > --- Urspr�ngliche Nachricht --- > Von: "Torsten Schlabach" <[EMAIL PROTECTED]> > An: [email protected] > Betreff: Re: [Web-cyradm] LDAP ... any preferences? > Datum: Mon, 16 May 2005 17:08:19 +0200 (MEST) > > 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 >
driver-demo.tar.gz
Description: GNU Zip compressed data
_______________________________________________ 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
