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

2011-06-30 Thread Matthew Barnes
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.

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.

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.


___
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)

2011-06-30 Thread Philip Withnall
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)

2011-06-30 Thread Matthew Barnes
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)

2011-06-30 Thread Ross Burton
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)

2011-06-12 Thread Philip Withnall
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)

2011-06-10 Thread Philip Withnall
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)

2011-06-09 Thread Matthew Barnes
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.

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.

I'm open to suggestions if you have any.

___
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)

2011-06-09 Thread Milan Crha
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