[SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command
Patrick Ohly
patrick.ohly at intel.com
Wed Jan 15 09:34:44 UTC 2014
On Tue, 2014-01-14 at 22:43 +0100, Helge Kraak wrote:
> Am 14.01.2014 um 15:32 schrieb Patrick Ohly:
>
> > On Tue, 2014-01-14 at 14:25 +0100, Helge Kraak wrote:
> > > When I apply as third command (no addressbook at the end of the
> > > command)
> > >
> > > syncevolution --configure SSLVerifyServer=False
> > > --template SyncEvolution_Client --sync-property
> > > remoteDeviceId=ST23K3J5I4JX username=admin
> > > password=admin --source-property addressbook/uri=addressbook
> > > sync=two-way Palm-TH55 at webdav
> > >
> > > the command
> > >
> > > syncevolution --print-config -q @webdav addressbook
> > >
> > > RETURNS:
> > >
> > > "[addressbook]
> > > backend = CardDAV
> > > database =
> > > https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/
> > > # databaseFormat =
> > > databaseUser = admin
> > > databasePassword = admin"
> >
> > When you show the config of addressbook for the Palm-TH55 peer, is
> > the
> > "sync" property set? In other words, what do you get from:
> > syncevolution --print-config -q Palm-TH55 at webdav addressbook
> >
>
>
> [addressbook]
> sync = disabled
[...]
> [addressbook]
> sync = two-way
[...]
>
> When I now initiate a sync I get:
>
>
> [INFO] syncevo-dbus-server: /org/syncevolution/Server: matched
> deviceID PN70M9J5V7JX against config palm-th55 at webdav
> (/root/.config/syncevolution/webdav/peers/palm-th55)
Okay, so it is as I thought - configuring unnecessarily/incorrectly
checks the source datatabase again and then fails to set the "sync"
property because it believes the source to be unusable.
I briefly considered disabling that check, but I think it is necessary:
otherwise users choosing a template may end up with a sync config which
has more sources enabled than possible in the context.
The check has to work, of course.
> [INFO] sync: /org/syncevolution/Session/15596840391389733215:
> addressbook: started
> [INFO] sync: /org/syncevolution/Session/15596840391389733215: adding
> "Jasmin Heinrich"
> [ERROR] sync: /org/syncevolution/Session/15596840391389733215: error
> code from SyncEvolution operation not allowed (remote, status 405):
> PUT: bad HTTP status: <status 1.1, code 405, class 4, Method Not
> Allowed>
So that's another issue to look at. You don't need a SyncML client for
it, just use "--import <file> @webdav addressvbook". For debugging
purposes, use "SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no
loglevel=4 --import ...".
That'll show the actual WebDAV commands. The SabreDAV server log may
also have additional information.
> The output of your suggested command above is (beneath I inserted the
> debugging output which I get for the split command version of yours
> with which I had come up before):
>
>
> root at srv:~/.config# SYNCEVOLUTION_DEBUG=1 syncevolution --configure
> SSLVerifyServer=False --template SyncEvolution_Client
> remoteDeviceId=PN70M9J5V7JX username=admin password=admin loglevel=4
> sync=two-way databaseUser=admin databasePassword=admin backend=carddav
> database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ Palm-TH55 at webdav addressbook[INFO 00:00:00] addressbook: looking for databases...
> [DEBUG 00:00:00] checking password property 'databasePassword' in
> source 'addressbook' of config 'palm-th55 at webdav' with user identity
> 'admin'
> [DEBUG 00:00:00] using username 'admin' from source config for WebDAV,
> password was set
> [DEBUG 00:00:00] using plain username/password for admin
> [DEBUG 00:00:00] addressbook: timout 300s, retry 5s => resending
> allowed
> HTTP session to https://localhost:443 begins.
> [DEBUG 00:00:00] client cert is missing
[...]
> [DEBUG 00:00:00]
> https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/: SSL verification problem: hostname mismatch, untrusted certificate
> [DEBUG 00:00:00] ignoring bad certificate
Okay, so SSLVerifyServer=False is working. The URL is the configured
one, too.
> [DEBUG 00:00:00] read relevant properties
> of /sabredav/addressbookserver.php/addressbooks/admin/
This is checking whether that URL actually is a CardDAV address book.
> [<?xml version="1.0" encoding="utf-8"?>
> <d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns"
> xmlns:card="urn:ietf:params:xml:ns:carddav"><d:response><d:href>/sabredav/addressbookserver.php/addressbooks/admin/</d:href><d:propstat><d:prop><d:current-user-principal><d:href>/sabredav/addressbookserver.php/principals/admin/</d:href></d:current-user-principal><d:resourcetype><d:collection/></d:resourcetype></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat><d:propstat><d:prop><d:alternate-URI-set/><d:principal-URL/><d:group-member-set/><d:group-membership/><d:displayname/><card:addressbook-home-set/><card:principal-address/><card:addressbook-description/><card:supported-address-data/><card:max-resource-size/></d:prop><d:status>HTTP/1.1 404 Not Found</d:status></d:propstat></d:response></d:multistatus>
> ]
And it turns out it isn't (none of the CardDAV properties are set). It's
a normal collection.
However, and that is the real problem, SyncEvolution doesn't check the
content of the collection. If it did, it would list its content and find
the actual address book(s) ("list items in ...").
Instead, the next step then is to check out the principal (= current
user) and see where its address books are (addressbook-home-set), but
that leads us just back to that same URL.
> [DEBUG 00:00:00] read relevant properties
> of /sabredav/addressbookserver.php/principals/admin/
[...]
> [<?xml version="1.0" encoding="utf-8"?>
> <d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns"
> xmlns:card="urn:ietf:params:xml:ns:carddav"><d:response><d:href>/sabredav/addressbookserver.php/principals/admin/</d:href><d:propstat><d:prop><card:addressbook-home-set><d:href>/sabredav/addressbookserver.php/addressbooks/admin/</d:href></card:addressbook-home-set><d:alternate-URI-set><d:href>/sabredav/addressbookserver.php/mailto:admin at example.org</d:href></d:alternate-URI-set><d:principal-URL><d:href>/sabredav/addressbookserver.php/principals/admin/</d:href></d:principal-URL><d:group-member-set/><d:group-membership/><d:displayname>Administrator</d:displayname><d:current-user-principal><d:href>/sabredav/addressbookserver.php/principals/admin/</d:href></d:current-user-principal><d:resourcetype><d:principal/></d:resourcetype></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat><d:propstat><d:prop><card:principal-address/><card:addressbook-description/><card:supported-address-data/><card:max-resource-size/></d:prop><d:status>HTTP/1.1 404 Not Found</d:status></d:propstat></d:response></d:multistatus>
> ]
It turns out, we were already looking at the URL under which the address
books are to be found. Because we already looked there, SyncEvolution
doesn't look again and gives up.
Where did the
database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ URL come from? Was it the result of a database discovery done by SyncEvolution? You can do that discovery without any config with:
syncevolution --print-databases \
backend=carddav \
syncURL=https://localhost:443/sabredav/ \
username=admin \
password=.... \
SSLVerifyServer=False
I expect that to fail, too, but it'll be easier to debug. How
comfortable are you using gdb and/or compiling from source?
I can't reproduce the problem with DAViCal, but I see a relevant
difference (DAViCal doesn't have a separate principal URL, so instead of
following that, SyncEvolution lists the content right away).
If my hunch is right, then uncommenting the "next.empty()" clause in an
if check in src/backends/webdav/WebDAV.cpp should fix it:
// finally, recursively descend into collections,
// unless we identified it as a result (because those
// cannot be recursive)
if (/* next.empty() && */ !isResult) {
// ^^^^^^^^^^^^^^^^^^
std::string type;
if (props) {
type = (*props)["DAV::resourcetype"];
}
if (type.find("<DAV:collection></DAV:collection>") != type.npos) {
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
More information about the SyncEvolution
mailing list