Re: [SyncEvolution] SyncEvolution + SSO + credentials

Hi all! I'm replying inline: > > -----Original Message----- > > From: Patrick Ohly [mailto:patrick.ohly@intel.com > <mailto:patrick.ohly@intel.com>] > > Sent: Friday, July 12, 2013 3:54 PM > > To: SyncEvolution > > Cc: ken(a)vandine.org <mailto:ken@vandine.org>; 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, > including > > > 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 <extendedHelp>https://code.google.com/apis/console</extendedHelp> > > 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 used > > 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).

And they can be overriden by the application, if it wants to. You can read more about that here: http://developer.ubuntu.com/resources/technologies/online-accounts/for-se...

> > 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:john.doe@gmail.com > <mailto:gSSO%2Bgoogle-calendar%3Ajohn.doe@gmail.com> > > password = > > > > Note the extra "+google-calendar": that tells SyncEvolution to use the > > "google-calendar" authentication method. How much it needs to know > > 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 additional parameters). 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.