On Sat, 2014-04-26 at 20:31 +0200, Emiliano Heyns wrote:
On Fri, Apr 25, 2014 at 10:23 AM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
On Fri, 2014-04-25 at 10:11 +0200, Emiliano Heyns wrote:
> On Thu, Apr 24, 2014 at 8:54 AM, Alberto Mardegan
> <alberto.mardegan(a)canonical.com> wrote:
>
>
> It's possible to inject an oauth token into UOA so
that
> syncevolution
> will use it. However, I'm not sure of how many
dependencies
> are required
> to have this working in Ubuntu Server. The packages
you
> definitely need are:
> syncevolution-provider-uoa
> account-plugin-google
> account-plugin-tools
Does SyncEvolution use "Device" or "Installed Apps" OAuth2
authentication for google?
This is left to GOA, UOA, and gSSO. I don't think SyncEvolution gets to
choose.
UOA and gSSO are a bit more flexible, though. Perhaps there is a way to
choose specific modes. I don't know.
With GOA, SyncEvolutions shares access that gets granted to GNOME. What
that is is hard-coded in GOA.
Because generating a device token is very easy. Even an installed
app
shouldn't be hard (I think this script capture the bulk of getting the
token:
https://gist.github.com/jotto/2932998), but whether that works
or not depends entirely on whether SyncEvolution uses GOA et al just
to get a token, or whether it uses GOA et all to handle much more of
the communication with Google. In the former case, I could just try to
add a shim that fakes getting the GOA token (or something to that
effect).
SyncEvolution needs the OAuth2 bearer string as returned by GOA in the
org.gnome.OnlineAccounts.OAuth2Based GetAccessToken method.
Have a look at src/backends/goa/goa.cpp. It doesn't do much, just wrap
GOA D-Bus API in the SyncEvolution AuthProvider API. Note that this API
already passes in both the configured username *and* password. It would
be possible to write a new auth provider which expects username/password
to be in the SyncEvolution config and then turns that into an access
token.
--
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.