Reported downstream at https://bugs.launchpad.net/ubuntu/+source/geary/+bug/1299255

1) elementary also uses AccountsSSO (a glib implementation), so the integration would be for more than just Ubuntu.

2) There is a $255 bounty on this bug. https://www.bountysource.com/issues/1352600-ubuntu-online-accounts-integration

Since there's a bounty for this now, let me lay down some basic stipulations we'll have to get this patch accepted.

First, it should be modularized so UOA support can be optionally compiled in.  We don't want Geary to have a hard dependency on UOA (or AccountsSSO) as it's not supported on every platform.  A ./configure switch should suffice.

In our internal discussions regarding single sign-on, we decided we wanted to add UOA to the list of ways to generate an account, not replacing the existing mechanisms.  For example, when creating an account with UOA support our thinking is that the dropdown list of services would look like this:

* Gmail
* Yahoo! Mail
* Outlook.com
* Gmail (user@gmail.com)
* Gmail (user.work@gmail.com)
* IMAP (user.home@example.com)
* Other

... where the services followed by email addresses represent accounts available via UOA.  We really don't want people to *have* to go through single sign-on in order to create a Geary account, but to make those SSO credentials available to ease setup.

As with our prior bounty, please use this ticket as a place to ask questions, discuss problems, and get clarity on how to proceed.  Don't be afraid to query us about the code, we're more than happy to point out where to look to solve the various problems this ticket poses.

Hey Jim,

If I understand correctly, you're saying that a user should both add their account in System Settings and also re-add it to Geary? I think the desired workflow for central online accounts management is that adding an account in System Settings should *automatically* add it to Geary.

I'm not 100% sure how UOA works, but in POA when you add an account you get a list of SSO using apps and a switch to turn on/off your account for that app. I think it would be confusing if a user turned on their account for Geary and then opened Geary to find that their account is not actually configured.

I can see that you'd probably still like users to be able to add and remove accounts from within Geary, but I don't think it's necessary to introduce an additional step here.

> If I understand correctly, you're saying that a user should both add their
> account in System Settings and also re-add it to Geary? I think the desired
> workflow for central online accounts management is that adding an account in
> System Settings should *automatically* add it to Geary.

I'm fine with that.  My thinking stemmed from knowing how much email the user could potentially be downloading if they added a lot of accounts at once then fired up Geary.  All I was suggesting was that they user would need to agree to create the account within Geary -- no configuration, just a "Yes, I want Geary to manage this account" button.  I didn't realize UOA had an option to turn service off/on for particular applications.

> I can see that you'd probably still like users to be able to add and remove
> accounts from within Geary, but I don't think it's necessary to introduce an
> additional step here.

I don't see a plain-jane IMAP/SMTP option in UOA, so users who have non-branded email will still need that option.  Also, as explained in my previous comment, I don't want Geary to have a non-configurable hard dependency on UOA.

Hey Jim,

Ah okay great. I think we're on the same page then :)

Here's a screenshot of UOA that shows the on/off switch. We do the same in POA: http://www.tecmint.com/wp-content/uploads/2013/04/Online-Accounts-Ubuntu-1304-Features.jpeg

I've also noticed that there isn't a generic mail account option. I've filed it as a bug report against POA.

I've taken a bit of a look at this over the weekend, and
(1) libaccounts does a lot less than I thought it should, and
(2) with not very much refactoring it should be possible to do an optional *OA backend.

The refactoring bit is because the providers tend to use oauth2 authentication rather than username/password which breaks the Geary.Credentials abstraction.

I'll keep hacking at this slowly over the next couple of weeks. I've marked this as assigned to me, but feel free to treat that as an advisory lock. If someone else can do it faster, great.

That would be great, your help is sincerely appreciated.  Please be sure to note some of the requirements above, as UOA (as well as GOA) should not be a hard requirement for Geary.

Absolutely. I have read the rest of the bug :).

Apart from the credentials refactor and a generic abstract SystemAccount everything should be sitting in its very own engine/uoa directory nicely segregated and optional.

Heya is anyone still actively working on this? I might take a stab at it if not but don't want to step on any toes here.

I've got a branch that almost implements enough of the SASL authentication dance to be able to login to gmail with XOAUTH2 in the geary console. That's one of the prerequisites to getting this working; I might be able to make it actually work and post the patch here this week.

You're welcome to take a stab at this if you want - as I mentioned, the time I've got for hacking on geary is limited, and the time I have for hacking on geary and feel like reading the relevant RFCs is even more limited :).

If you wanted to start with the get-an-OAUTH-token-from-UOA bits (check out the patch to evolution-data-server in the Ubuntu source package), the UI bits, or refactoring the Geary.Credentials bits then hopefully I can provide you with a working actually-login-using-OUATH patch by the time you need it :)

Christopher, can you link to the branch you're working on?

Sure. It's not useful at the moment, is messy, and all the usual disclaimers:

https://github.com/RAOF/geary

The online-accounts branch now implements enough SASL to authenticate with Google (and, presumably, everyone else. Because they'll all be perfectly standards compliant, right?).

It's still full of hacks and “I wonder if this makes it work...”, though.

Christopher, thanks for your patience.  Looking at this I see that this is a good start.  If nothing else, getting the AUTHENTICATE command implemented is a big leap forward.

One thing I question is placing the authenticate code in ClientConnection.  I believe AUTHENTICATE can be treated as yet another IMAP command and can be handled by ClientSession.  It may not even require adding new states/events to ClientSession; like STARTTLS and COMPRESS, ClientSession.initiate_session_async() might be the place for this code.  Geary could detect AUTHENTICATE is available and use that instead of LOGIN.

I don't see in this branch any UOA-specific code (other than some test code), so I assume that's work that needs to be done.

The reason I'm treating AUTHENTICATE specially is because it seems pretty special - it immediately drops the connection into a command-continuation-ish SASL session; even with SASL-IR the client needs to acknowledge the server-response with a CRLF.

Huh. I hadn't actually noticed ClientSession. I think you're right; that's a better place to encapsulate this.

I can see that, and for a certain kind of command that might make sense.  (That's why IDLE is handled by ClientConnection, not ClientSession, because it's truly putting the connection into a certain state, sort of like XON/XOFF.)  But for one-off things that need to happen when a connection is being established, initiate_session_async makes life a lot easier.

One thing to understand: it's implicit in the contract for initiate_session_async that the caller won't issue any more commands while the call is outstanding (although they're free to disconnect_async at any time).  Maybe we should make that clearer in the documentation, but that's certainly how it's being used in the code today.

Christopher, you should also be aware of bug #713745, support Google 2-step authentication.  It may be that getting the authentication stuff in place is the first step, then return to this ticket and integrate with UOA.  What do you think?

Also, bug #713860

I'm pretty sure that Google 2-step authentication is mostly equivalent to *OA integration + doing the OAUTH2 dance manually. AUTHENTICATE support will unblock both.

I'll probably still do UOA support first, because that means I don't have to work out how to spawn a webview, capture whatever cookies happen to be appropriate, and handle the OAUTH2 response.

I can't see any progress here, so I'll start working on this issue.

Yes! If anyone feels like taking what's in https://github.com/RAOF/geary and running with it you're most welcome to. I don't have significant free time to dedicate to it, so you'll probably be able to do it faster :)

The discussion on the GOA ticket (bug #714876) is relevant to this ticket as well.

I'm struggling with libaccounts and libsignon.
I know how to get SSO,but I don't know how to add an account of geary.

You'll need to look at the code in src/client/accounts.  You should also look at src/engine/api/geary-engine.vala and geary-account-information.vala.

I want the manifest file of UOA,geary.applicaion to install ,but the rule to write CMakeList.txt and intltool and getttext settings.
I want someone else helps me.

I tested geary can get account,
But those points are not clear.
 The way to add an account automatically.
 Grammer of cmake and intltool.
 If a user disabled an account ,should I delete it from geary?

I didn't notice till now,but Google Gmail support need application to Google Apps.
It needs money...
I know it is easy to use Evolution's client id and key,but if Evolution team don't give a permition to geary,we could not support gmail.(maybe)

Oh,I found it is okay to use picasa's client id.

Integration UOA is fine, but I still want to have an option to configure any account from the client itself like evolution does. 

UOA is full of bugs and I have to reauthorize same account(read Google) 10 times in a month. Besides, UOA does not even support IMAP,let alone configuring it.And the situation is not going to change anytime soon.

It is okay to have an option.
I think it is not a bug of UOA but Google's policy.

Created attachment 304316 [details] [review]
Patch part1

This patch is just for adding UOA manifest file.

Hi Akira, are you still interested in working on this? There's some activity happening over in the bug for GOA (Bug 714876), which would also help out with UOA support.

In general, as mentioned in comment 11 of that bug, the UOA SSO model should be as follows:

 - UOA IMAP+SMTP accounts should automatically be added to Geary but will be able to be disabled (Bug 768974)
 - Geary would still need to store account-specific config for the UOA accounts independently of the auth information that UOA provides, hence needs a geary.ini file still. E.g. signatures and alt addresses.
 - Some under the hood work is needed to support pluggable endpoint config and auth mechanisms (Bug 768975)

Ubuntu Online Accounts is no longer supported by Canonical since Ubuntu is switching to GNOME and GNOME Online Accounts.

Therefore, I'm closing this bug.