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. 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 “google.com” (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]: http://git.gnome.org/browse/libgdata/tree/gdata/gdata-authorizer.h > I'm open to suggestions if you have any.
Attachment:
signature.asc
Description: This is a digitally signed message part