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 username/password): • https://bugzilla.gnome.org/show_bug.cgi?id=652392 • https://bugzilla.gnome.org/show_bug.cgi?id=652394 Philip > 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. >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
