LDAP backend for CardDAV
Andreas Dick
wow, sabredav is just what I wanted for serving my addressbooks: two of my
favorite clients (KDE Kontact and CardDAV sync App for Android) works
well with my new sabredav server!
On the other hand, I have clients like Roundcube and Thunderbird where LDAP as
backend is the best choise for today!
I write this email because I wrote a CardDAV backend for sabredav that
connects to my homebrew openLDAP server holding all my contacts... and yes, I
am verry surprised how easy it was to extend the existing PDO class.
Could it be that there is some interest by others for such a extension?
Of coarse, the design of the code is not like it could be compared with the
code of sabredav, but on LDAP side it is free configurable and extensible.
The attached file is an extension of Sabre_CardDAV_Backend_PDO since I still
use the PDO for the addressbooks... just the contacts are stored in the LDAP.
Since I do not know the thoughts behind sabredav, I still have some problems:
- how to handle propre exceptions if something goes wrong or is not allowed,
such that the client can show a message about?
- how to implement a sabredav like logging?
- how to identify the clients for workarounds (e.g. utf8 problems with
Kontact, today I do it with seperate url's)?
Now, please let me know if sabredav is willing to take over this code... if
yes, feel free to redesign it... if no, maybe this could be something for the
wiki... or even, forget this email :-)
Andreas
Evert Pot
On Jan 14, 10:28 pm, Andreas Dick <aend...@gmail.com> wrote:
> dear sabredav devs
>
> wow, sabredav is just what I wanted for serving my addressbooks: two of my
> favorite clients (KDE Kontact and CardDAV sync App for Android) works
> well with my new sabredav server!
>
> On the other hand, I have clients like Roundcube and Thunderbird where LDAP as
> backend is the best choise for today!
>
> I write this email because I wrote a CardDAV backend for sabredav that
> connects to my homebrew openLDAP server holding all my contacts... and yes, I
> am verry surprised how easy it was to extend the existing PDO class.
>
> Could it be that there is some interest by others for such a extension?
>
> Of course, the design of the code is not like it could be compared with the
>
> The attached file is an extension of Sabre_CardDAV_Backend_PDO since I still
> use the PDO for the addressbooks... just the contacts are stored in the LDAP.
>
> Since I do not know the thoughts behind sabredav, I still have some problems:
> - how to handle propre exceptions if something goes wrong or is not allowed,
> such that the client can show a message about?
errors altogether, but otherwise you are stuck to just emitting
exceptions. There's a whole bunch in Sabre/DAV/Exception/
> - how to implement a sabredav like logging?
bunch of events:
http://code.google.com/p/sabredav/wiki/WritingPlugins
There's a 'debugplugin' branch on git that adds a ton of logging, but
it's not finished.
> - how to identify the clients for workarounds (e.g. utf8 problems with
> Kontact, today I do it with seperate url's)?
Can you elaborate? At the moment it's not possible at all to get
information about the request from the backend classes, because these
things 'should' be separated.
Client workaround are typically handled in plugins, such as
Sabre_CardDAV_Plugin.
>
> Now, please let me know if sabredav is willing to take over this code... if
> yes, feel free to redesign it... if no, maybe this could be something for the
> wiki... or even, forget this email :-)
needs to be fully unittested, and perhaps cleaned up a bit. It would
probably be good for the project to have a 'contrib' section, as there
was also someone who created a full-on amazon s3 connector.
Andreas Dick
> errors altogether, but otherwise you are stuck to just emitting
> exceptions. There's a whole bunch in Sabre/DAV/Exception/
I added a line like:
throw new Sabre_DAV_Exception_BadRequest($str);
such that the client get informed about backend errors, even if they do not
use it.
> > - how to implement a sabredav like logging?
>
> You could go pretty far by creating a plugin and handling a whole
> bunch of events:
> http://code.google.com/p/sabredav/wiki/WritingPlugins
>
> There's a 'debugplugin' branch on git that adds a ton of logging, but
> it's not finished.
my implementation is quiet easy, feel free to replace or cut it.
> > - how to identify the clients for workarounds (e.g. utf8 problems with
> > Kontact, today I do it with seperate url's)?
>
> I'm interested in hearing exactly what type of errors you're seeing.
> Can you elaborate? At the moment it's not possible at all to get
> information about the request from the backend classes, because these
> things 'should' be separated.
well, I do not mean protocol errors, but errors in the format of the content.
Normally sabredav just stores the VCARD and delivers it back, thus if only
Kontact would use it nobody would find it out:
1) groups are in standard VCARD implemented with "CATEGORIES", using more than
one group is implemented with a coma seperated list, if a group name contains
a coma, it is escaped with a backslash, like:
CATEGORIES: groupA,groupB\,C
means one group "groupA" and another "groupB,C"
-> Koncat uses it just inverted, meaning that it would be a group
"groupA,groupB" and another group called "C"
2) sending VCARDs to Kontact, the CATEGORIES field must be encoded as utf8. if
not, German umlaute (and all characters > 127) are coded wrong.
Even worse, every time saving a contact in Kontact, the categories field is re-
encoded... so utf8 of utf8 of ... (this doesnt matter as long as you do not
use utf8) (I am not yet sure if this is only a problem of the groupDAV
connector...)
-> my workaround is to encode the CATEGORIES field with utf8 while delivering,
and to dissallow creating of new groups on server side
-> see my LDAPkontact.php attached, that implements the workaround. I use for
Kontact a different url to access sabredav, see my ".htaccess" attached.
> Client workaround are typically handled in plugins, such as
> Sabre_CardDAV_Plugin.
-> my question is if sabredav could find out due to the protocol what client it
talks with, such that this url-trick is not necessarry?
> > Now, please let me know if sabredav is willing to take over this code...
> > if yes, feel free to redesign it... if no, maybe this could be
> > something for the wiki... or even, forget this email :-)
>
> It's great. It's not ready for integration into SabreDAV, because it
> needs to be fully unittested, and perhaps cleaned up a bit. It would
> probably be good for the project to have a 'contrib' section, as there
> was also someone who created a full-on amazon s3 connector.
how do you think this unittest could look with the LDAP server? it will not
run out of the box if no server is accessible...
let me know when you integrate and commit something, I am willing to test it
:-)
Andreas
Marc Laporte
I am very interested for the Tiki Suite project: http://suite.tiki.org/
Client components: Thunderbird + LibreOffice + CyberDuck + Jitsi
Server components: Tiki + ClearOS (incl OpenLDAP) + BigBlueButton +
Kaltura + ejabberd + blue.box/FreeSWITCH + Clipperz + Piwik
So contact sync/management is important...
Thanks!
M ;-)
--
Marc Laporte
http://MarcLaporte.com
http://Tiki.org/MarcLaporte
http://AvanTech.net
Andreas Dick
> Hi!
>
> I am very interested for the Tiki Suite project:http://suite.tiki.org/
>
> Client components: Thunderbird + LibreOffice + CyberDuck + Jitsi
>
> Server components: Tiki + ClearOS (incl OpenLDAP) + BigBlueButton +
> Kaltura + ejabberd + blue.box/FreeSWITCH + Clipperz + Piwik
>
> So contact sync/management is important...
I can just help you on the LDAP back side, the dav front is not my
busines :-)
Andreas