On Wed, 2016-10-19 at 04:06 -0700, Dave Cole wrote:
> On Wed, 2016-10-19 at 06:56 -0400, Benjamin Selzer wrote:
> > On Tue, 2016-10-18 at 13:54 -0400, Benjamin Selzer wrote:
> > > No joke it seems to happen to me around the end of the day as if
> > > I'm hitting so.e artificial Google limit on calendar sync.
> >
> > Same here... I have reduced the number of time I refresh to see if
> > that corrects things...
>
> I get it not just for Calendar, but for Contacts as well...
Hi,
just a little update on the GOA issue. There is opened bug
https://bugzilla.gnome.org/show_bug.cgi?id=773248
thus let's use it. I'll write the story here, but then let's move to
the bug report. Also, the above is for GOA-configured accounts, while
the below is for Google accounts configured directly in the evolution:
https://bugzilla.gnome.org/show_bug.cgi?id=771547
Both ways to connect to the Google services have/had some issues
specific to the respective method, but also some common issues.
And now the story:
I added some more debug prints into the code yesterday, to have things
ready for the investigation. I ran the evolution with it yesterday too,
but nothing obvious stroke. I turned off the machine yesterday. In the
morning, I turned on the machine, run my services with added debugging
and let the evolution to open one of the Google calendars which I have
configured through GOA. The first thing what the server did was a
reject of my request with the error:
| Daily Limit Exceeded. The quota will be reset at midnight Pacific
| Time (PT). You may monitor your quota usage and adjust limits in
| the API Console: https://console.developers.google.com/apis/api/cald
| av/quotas?project=923794261470
Note it was my first attempt to connect to the server on this machine
and even I'm +6 hours from the Eastern Time, I do not think it has many
things to do with it. Following on, I suspended the machine and went
out (there is a bug where GOA can go crazy due to instant requests from
the evolution-calendar-factory after suspend, when the network changes
and/or is unavailable, thus I wanted to verify that too). After almost
an hour I turned on the machine, with no network connection. I didn't
reproduce the issue with the GOA being spammed by the calendar factory,
but I noticed one issue which can be related and which I'm going to fix
after I'll finish this email. Back to the initial issue, the server
still claims the "Daily Limit Exceeded" error, even I use a valid
OAuth2 token. The error message is different, when I do not use any
OAuth2 token. I do not have the exact error in the back log, if I
recall correctly, then it says something like "Continued use requires
authentication", or something along those lines. Moving on, I see that
the CalDAV backend updates its own copy of the libsoup authorizer, but
libsoup itself uses a different object, with an old OAuth2 token. That
will cause trouble after an hour, when the token expires.
Why do I talk about CalDAV, and not about libgdata sources, like the
Tasks and Contacts, or even about Mail? It's because I'm pretty sure
the trouble maker is CalDAV here. Why do I think so? It's from the
above observations. I think (and only think, I really do not have any
insight on the Google server internals), based on those observations,
that the Google server counts how many times a particular account tried
to connect with a wrong token and once the limit is reached, it'll
simply block the account for the rest of the day, possibly for security
reasons. Note that this account has nothing to do with the users, this
account is an account which register developers of 3rd-party
applications, which would like to connect to Google services using
OAuth2 authentication (which the Google server forces on most of its
services these days, for a good reason). There is one such Google
developer account used by GOA, and one by the evolution-data-server.
This Google developer account is shared by all the users of the
respective, well, services (but this time the services on the client
side, thus GOA or evolution-data-server (directly configured Google
accounts in the evolution)). Still remember how I begun above, my first
connection of the day and I've got kicked off by the server
immediately. That's why I think this.
I do not know how large the limit is. It would be interesting to know.
Nonetheless, I'm afraid that whatever I'll do in the current stable and
the development version to address the issue, it'll still be here, as
long as people will use unpatched versions, not talking about long time
support distributions offering users so called stable, but otherwise
ancient, versions of the evolution-data-server. These users will
(unintentionally, I really do not blame them, the issue is on the eds
side) trigger the error to the users of the most recent evolution-data-
server, due to locking the Google developer account with too many
requests with expired tokens.
Remember, these are only my thoughts, made up of the observations. I
can be wrong in any and all of that.
I'm going to dive into this a bit more, to fix what I've found on the
CalDAV side. Thanks for reading this far.
Bye,
Milan
_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
