On Mon, 2013-07-15 at 09:23 +0300, Alberto Mardegan wrote:
I'm replying inline:
> > -----Original Message-----
> > From: Patrick Ohly [mailto:firstname.lastname@example.org
> > Sent: Friday, July 12, 2013 3:54 PM
> > To: SyncEvolution
> > Cc: ken(a)vandine.org <mailto:email@example.com>; Laako, Jussi;
> Kanavin, Alexander
> > Subject: Re: SyncEvolution + SSO + credentials
> > On Thu, 2013-07-11 at 17:07 +0200, Patrick Ohly wrote:
> > > - Walk through specific flow for Google CalDAV and CardDAV,
> > > the configure options needed to provide the keys and what the SSO
> > > backend would get from SyncEvolution.
> > Let's consider a naive attempt to use Google CalDAV:
> > $ SYNCEVOLUTION_DEBUG=1 syncevolution --print-items --daemon=no
> > backend=caldav loglevel=4
> > syncurl=https://apidata.googleusercontent.com/caldav/v2
> > The commands fail with "403 Forbidden" and a rather unspecific
> > application/vnd.google.gdata.error+xml error which points towards the
> > need to register the app (see google-caldav.log, attached).
> > From that the client may conclude that it is dealing with a Google
> > service. But that could be misleading. For example, what if some other
> > service uses the same error format?
> > The
> > is a bit more Google specific, but looking at the content of a help
> > text just doesn't feel right.
> > IMHO this boils down to the need to determine the authorization method
> > beforehand. According to
> > https://developers.google.com/accounts/docs/OAuth2InstalledApp
> > https://developers.google.com/google-apps/calendar/auth
> > the following pieces of information are needed for OAuth2:
> > end point: https://accounts.google.com/o/oauth2/auth
> > scope: https://www.googleapis.com/auth/calendar
> > client_id: xxxx
> > redirect_uri: as registered for that client_id
> > Is the end point something that must be passed to (g)SSO or is it
> > something that it already knows? What "redirect_uri" should be
> > when registering SyncEvolution?
All this information (end point, scope, client id, redirect uri) can be
known by libaccounts-glib itself, if stored in a .service file in
/usr/share/accounts/services/ (if you use a recent Ubuntu distribution,
you can already see what's in there).
If I were to try that in a chroot, which packages do I need to install?
And they can be overriden by the
application, if it wants to.
You can read more about that here:
"creating a binary plugin which the Online Accounts configuration applet
will load" - while that may be useful for best integration into Ubuntu
(or Ubuntu Phone), this is not something that I want to depend on in
core SyncEvolution. I would accept patch contributions for an optional
component, if someone wants to write and maintain such a plugin as part
The key part would be to figure out whether the user wants to sync a
certain calendar or address book, then create the corresponding local
EDS database, SyncEvolution config and trigger syncing.
I think SyncEvolution should not do that automatically. Otherwise
enabling, say, the Google account in UOA for Evolution and installing
SyncEvolution for syncing with a phone would suddenly end up mirroring
> > The information above could be provided to
SyncEvolution at runtime in
> > a /usr/share/syncevolution/authentication/google-calendar.ini
> file. The
> > content of that file is determined by the packager. In addition, files
> > could also be searched for in
> > ~/.local/share/syncevolution/authentication
> > or /etc/syncevolution/authentication. That way, a user and/or system
> > admin could personalize or add services without having to recompile
> > SyncEvolution.
> > To use OAuth2, the user would need to use:
> > username = gSSO+google-calendar:firstname.lastname@example.org
> > password =
> > Note the extra "+google-calendar": that tells SyncEvolution to
> > "google-calendar" authentication method. How much it needs to
> > about the method is open for debate - it could be treated as key/value
> > store whose pairs SyncEvolution simply passes through to the SSO
> > backend without caring about the content, or it could simply pass the
> > string itself to the backend and let the backend resolve it.
The libaccounts backend doesn't need any of that information:
libaccounts will know how to enumerate the accounts which are
interesting for SyncEvolution, and will be able to authenticate against
them. It will return the credentials information (OAuth token,
username/password pair) plus the information of what this information is
(whether it's a token or username/password). It can also return other
information about the service (such as the server URL and port, and
What I wonder about here is: can't we just reuse the libaccounts (or
GOA) backends we have for Evolution? After all, to me it looks like they
would perform exactly the same task.
Probably yes, with one caveat: can CardDAV be used for Google? Evolution
itself uses the GData API. The client ID would be the same for each app
in this case, right?
I've looked at the EDS backend for UOA. It has the code which retrieves
the OAuth2 token. I could do something similar in SyncEvolution.
EDS does not seem to have the actual libaccounts backend. Where is that
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.