[Replying to the list with Todd's permission]
On Mon, 2014-04-14 at 17:55 -0700, Todd Wilson wrote:
Patrick,
This is my first question about the Google side of my attempted sync
set-up, so I'm starting a new thread. I'm using
http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/src/backend...
as a resource. Here are the steps I've taken so far:
1. As a precaution, I started up GOA, deleted my Google Account, and
re-added it, authenticating successfully inside the GOA application.
Which version of GOA, which distro, and what permissions where you asked
to grant?
It is important that "Google Calendar" and (for Google Contacts) "Google
Contacts via CardDAV" appear there. Yes, Google distinguishes between
Google Contacts via their own API and CardDAV.
2. I went online to my Google Account and verified, under Recent
Activity, that I've signed in (Linux). Under Account Permissions, it
says (among many other things, of course):
* Ubuntu: Has full access to your Google Account (Auth date:
aaaa/2014)
* Ubuntu: Has access to Google Drive, Google Talk, Picasa Web
Albums, basic account info (Auth date: yyyy/2013)
* GNOME: Has access to Gmail, Google Calendar, Google Contacts,
Google Docs, Google Drive, basic account info (Auth date:
xxxx/2011)
I'm not sure why these old connections are there, or why the most
recent connection wasn't dated today because of what I did in Step 1.
Not sure either.
3. I checked with seahorse and found an entry "GOA google
credentials
for identity account_1322264161" (Gnome Online Accounts password). I
also found "Network passwords" for "xxxxx(a)zimbra.yyyyyy/dav/twilson"
and "xxxxx(a)zimbra.yyyyyy/dav/twilson/Calendar". Are those the entries
created by syncevolution in my Zimbra sync? Do I need both?
Probably yes. If you look at the details of these network passwords,
you'll see that SyncEvolution includes the full path as "server" key, so
the two entries really are different. Whether they are still in use is a
different question.
Here's what it has stored for me for Google CalDAV:
server:
www.google.com/calendar/dav/%u/user/?SyncEvolution=Google
user: patrick.ohly(a)googlemail.com
The "server" and "user" values are used to find the stored
"password"
value. I've not found good instructions for choosing keys. Make them too
specific and you end up with more entries than necessary and the user
has to fix them multiple times when changing the password on the server.
Make them too unspecific and different passwords will conflict with each
other. For example, an HTTP server might require different passwords for
different paths, which is why SyncEvolution includes the path in the
key.
4. Using the account information I got from Step 3, I entered the
command
$ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --print-databases
backend=caldav username=account_xxxxxxx
^^^^^^^^^^^^^^^^^^^^^^^^^^^
You need to tell SyncEvolution that you want to use GOA. This has to be
username=goa:account_xxxxxx.
5. In seahorse again, I can look at the password for
account_1322264161 and it looks like
{'access_token', <'...'>,
'access_token_secret':<'...'>}
with no resemblance to my password, so I can't check to see if it's
stored correctly, but I assume it is since there was no error where I
created the account and Google says I'm logged in.
This is indeed normal. One of the advantages of OAuth is that the actual
password for the login doesn't need to be stored. The password allows
the application to do anything it wants with your Google account. The
OAuth tokens restrict access to those services that were requested and
granted.
6. I ran the command from Step 4 again with loglevel=4. I won't
flood
this email with the output (unless you want to see it), but I note
that the 403 was accompanied by a response body that included
<error>
<domain>usageLimits</domain>
<code>dailyLimitExceededUnreg</code>
<internalReason>Daily Limit for Unauthenticated Use
Exceeded. Continued use requires signup.</internalReason>
<
extendedHelp>https://code.google.com/apis/console</extendedHelp>
</error>
and the 401 was accompanied by a response body that included
<error>
<domain>GData</domain>
<code>authError</code>
<location type="header">Authorization</location>
<internalReason>HTTP Basic Authentication is not supported
for this API</internalReason>
</error>
This confirms that SyncEvolution was attempting normal HTTP Basic Auth
with a blank password, which would have been wrong, even if it had been
supported for this particular path (which it isn't).
As reported recently on the list, the old CalDAV URL still works with
Basic Auth, but that will be turned off eventually.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.