Re: [Evolution-hackers] GOA Integration (was: New 'eclient' branch in eds)

On Fri, 2011-06-10 at 17:02 +0100, Philip Withnall wrote:
> On Thu, 2011-06-09 at 17:24 -0400, Matthew Barnes wrote:
> > On Thu, 2011-06-09 at 21:56 +0100, Philip Withnall wrote:
> > > I guess this involves updating the Google Contacts address book backend
> > > to use GOA's OAuth 1.0 magic. I've recently updated libgdata to be able
> > > to cope with OAuth, and I've got an (untested) patch to e-d-s to update
> > > it to use libgdata's shiny new authorisation API. Over the next few days
> > > I intend to test it properly and fix it up.
> > > 
> > > I hope this fits in well with what you've been conscripted to do re.
> > > GOA.
> > 
> > Having just started on it this week, so far I'm mostly just concerned
> > with keeping Evolution synchronized with any Google online accounts.
> > 
> > But yeah, I was hoping libgdata would make things magically work for
> > address book authentication.  And I think I have a handle on the mail
> > side -- just need to extend our CamelSASL framework to handle XOAUTH
> > from outside of Camel.
> libgdata's new API implements authentication/authorisation using a
> GDataAuthorizer interface[1]. At the moment, libgdata has
> implementations of this interface for ClientLogin (Google's old
> username/password auth system) and OAuth 1.0. The patch I've got for
> e-d-s converts the Google Contacts address book backend to use
> libgdata's ClientLogin authoriser to keep up with libgdata's rampant API
> breaks.

Since I've now released libgdata 0.9.0, here are the patches for evo and
e-d-s to port them to the new authentication mechanism (but still using


> What I've been discussing with davidz is the implementation of some sort
> of GnomeOnlineAccountsAuthorizer class (in e-d-s' Google Contacts
> backend?) which implements GDataAuthorizer and just sticks GOA's OAuth
> 1.0 tokens onto every request.
> This would work for Google Contacts.
> > Google Calendars have me stumped, however, since we defer to our
> > standard CalDAV backend which authenticates with stored passwords from
> > the keyring.  I'm not sure how to slip in OAuth integration for this one
> > special case.
> Hmm. I guess either the standard CalDAV backend could be modified to use
> OAuth if the domain name matches “” (or whatever); or the
> Google Calendar backend could be resurrected with special authentication
> code, but sharing the CalDAV code with the normal CalDAV backend.
> Philip
> [1]:
> > I'm open to suggestions if you have any.

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]