Re: [Evolution-hackers] GOA Integration (was: New 'eclient' branch in eds)
On Thu, 2011-06-30 at 13:45 -0400, Matthew Barnes wrote: On Fri, 2011-06-10 at 17:02 +0100, Philip Withnall wrote: On Thu, 2011-06-09 at 17:24 -0400, Matthew Barnes wrote: 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. Just to follow up on this... I wrote a custom SoupAuth class for OAuth. Instead of calling soup_auth_authenticate() on it, you would instead call a different function that takes the consumer key, consumer secret, token and token secret strings as parameters, which the GNOME Online Accounts API provides. That's a neat idea. Perhaps it would be worthwhile putting this in libsoup proper so that we have a common place for OAuth implementations. It does seem to be the right place. Turns out it was all for naught, because I later realized Google's CalDAV interface currently only supports Basic HTTP authentication. Haven't seen any indication that OAuth support is forthcoming. That's unfortunate. Google don't seem to really love the Calendar APIs or CalDAV interface much. :-( Philip So that kinda sucks; users will still have to enter a password to access the calendar even if they have a valid access token. But it does mean GOA integration in Evolution is pretty much done for now and I can get back to other priorities. I'll keep my little SoupAuth class around in case the situation with Google's CalDAV interface changes. 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
Re: [Evolution-hackers] GOA Integration (was: New 'eclient' branch in eds)
On Thu, 2011-06-30 at 18:34 +, Philip Withnall wrote: That's a neat idea. Perhaps it would be worthwhile putting this in libsoup proper so that we have a common place for OAuth implementations. It does seem to be the right place. Once I can verify that it actually works I'll see if Dan's interested, although he did point me to librest, which is libsoup-based and provides more complete OAuth support than my little hack. http://git.gnome.org/browse/librest/tree/rest (can't find any online API docs for it) It's looking like GLib might get HMAC support soon too, so we could sign tokens without liboauth's help. https://bugzilla.gnome.org/show_bug.cgi?id=652480 That's unfortunate. Google don't seem to really love the Calendar APIs or CalDAV interface much. :-( I posted a question about it in their Calendar API forum. We'll see... http://code.google.com/apis/calendar/community/forum.html?place=topic%2Fgoogle-calendar-help-dataapi%2F1uyk2pk9yHI%2Fdiscussion ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GOA Integration (was: New 'eclient' branch in eds)
On 30 June 2011 19:45, Matthew Barnes mbar...@redhat.com wrote: Once I can verify that it actually works I'll see if Dan's interested, although he did point me to librest, which is libsoup-based and provides more complete OAuth support than my little hack. http://git.gnome.org/browse/librest/tree/rest (can't find any online API docs for it) Oh, I should sort that out. librest has gtk-doc and almost reasonable coverage. It's looking like GLib might get HMAC support soon too, so we could sign tokens without liboauth's help. librest does HMAC too, if you fancy copy-and-pasting some crypto code. ;) I will pimp librest and say that if you have any questions about it, please ask. Ross ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
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 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
Re: [Evolution-hackers] GOA Integration (was: New 'eclient' branch in eds)
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. 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
Re: [Evolution-hackers] GOA Integration (was: New 'eclient' branch in eds)
On Thu, 2011-06-09 at 17:24 -0400, Matthew Barnes wrote: 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. Hi, I do not know much background of OAuth, (to be honest, none at all), thus this is rather a question than answer: CalDAV is using libsoup to connect to the Google's calendar server and what you are dealing with is that you do not know how to tell CalDAV to use OAuth and how to pass it from the UI part to the backend, supposing the libsoup is capable of this OAuth feature? If so, then that might be pretty simple with EClient (on actual git master), just do: a) in e-client-utils.c::e_credentials_authenticate_helper check for which account you are asking credentials and set some key in ECredentials to indicate you are offering OAuth token b) in CalDAV backend, in authenticate_user handler, check for the key from a) and pass either user/password or OAuth to libsoup, based on its presence. Hope that helps, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
