---- Reported by firstname.lastname@example.org 2011-06-21 12:12:24 +0000 ----
From the "[SyncEvolution] configuration of CalDAV/CardDAV" mail thread:
We have "username", "password", "syncURL" properties. If "password" is
"-", then reading credentials looks up the password based on the given
username and the syncURL in the GNOME keyring (or soon, KWallet). The
"server" and "user" keys are used as search filter, with "server" equal
to the syncURL minus the method prefix (i.e., http:// and https://
Storing a "password" not equal to "-" will automatically set the
password value in the keyring if its usage is enabled (on by default in
the D-Bus server, off in the command line).
Retrieving the config via D-Bus transparently retrieves the credentials
and sends them to the D-Bus client.
I'd like to extend this so that the username doesn't have to be know in
advance, and so that CalDAV and SyncML can refer to the same server
despite having different syncURLs.
"credentials = URI": Defines where credentials are stored. The empty
string (default) is the traditional approach.
"gnome://server=<server>[&user=<user>]" takes username and password from
the corresponding entry. "kde://" does the same for KWallet.
"keyring://" is an alias for the default keyring (depends on how the
binary was compiled and runtime environment). Saving a config will
always update the "credentials" property with the actual location.
Here are some use cases for this:
* The "google" and "google-calendar" configs will have
"credentials = keyring://server=google" set. In the case of
"google-calendar", both the sync and source configs have that.
That way all three configs use the same username/password
automatically. It forces command line users who do not want to
or can't use a keyring to configure with empty "credentials";
they can't share credentials.
* After configuring via the D-Bus interface, the command line will
automatically enable the right access method for the
credentials. It is no longer necessary to explicitly say
* A future extension would use either a different method or
additional parameters in the URI to define some other
authorization method. The current implementation must throw an
error when running into something it doesn't know.
Nothing needs to be done in the UI or the command line to support this.
The only changes will be in the current code which talks to the
--- Bug imported by email@example.com 2012-07-29 20:36 UTC ---
This bug was previously known as _bug_ 19665 at https://bugs.meego.com/show_bug.cgi?id=19665
*** Bug 52688 has been marked as a duplicate of this bug. ***
Implemented since SyncEvolution 18.104.22.168, together with single-sign-on support.