Need to authorize my google account each time I boot the computer

Thanks for reporting this bug. There are many possible causes why this could happen, so please bare with us while we try to sort them out and fix them. :-)

Hopefully the new 0.6 release (it should appear in a few days) of signon-ui will help improve the situation.

Now the fix should have been landed in Quantal (signon-ui 0.6); could you please update to the latest signon-ui and try again?

(you will indeed have to authorize the account once more, but after that it should keep you logged in for a longer time)

For what it's worth: after upgrading to account-plugins 0.7-0ubuntu1, I've had to re-auth to google twice, so far today. On logging in, each time. There may have been one login where I didn't have to...I don't remember so well. Thanks.

I am still seeing this behavior on Quantal--up to date as of this morning. My signon-ui is version 0.11-0ubuntu1, if that makes a difference. I have one account with standard google logon and another with 2-stage authentication. I see this behavior with both.

For the record, the two-stage authentication works fine...google asks for my regular password and then for my authentication code from the phone.

Thanks Richard and Edward for your feedback.

As usual, I need to ask you a few more questions to investigate the issue:
1) When you re-authenticate, is the "Stay signed in" checkbox checked?

The following requires some familiarity with the command line, so don't feel obliged to answer if it sounds too difficult. From a terminal:

  sudo apt-get install account-plugin-tools
  account-console list

now see the id of the google account. Suppose that it is 1234, and substitute that in the following command:

  account-console show 1234 | grep Cred

remember what is the value of CredentialsId; let's suppose that it's 4321, and let's substitute it in the following command:

  strings ~/.cache/signon-ui/cookies/4321.jar

Could you please paste the output of the last command *AFTER ALTERING THE VALUE* of the sequence of semi-random number of chars on the right of the "=" signs (just remove a few of them, and insert some random ones)? Please do not modify the rest. :-)
(don't post the full unmodified output it here: some malicious people could use it to gain access of your google account)

Thanks, mardy. I haven't had this problem for a few weeks now. My account is a google apps domain, and I use only the regular single authentication. I'll post if I see any problems, but everything has settled down here.

I altered the output as suggested and here it is: (I still have this issue):

 ~/.cache/signon-ui/cookies/1.jar

KGoogleAccountsLocale_session=en; secure; domain=accounts.google.com; path=/
<GALX=AlCamgbbjxg; secure; domain=accounts.google.com; path=/
NID=64=mQB-BV6KIQzrKYAi7j5OP1Qufr6syYHZd8ltzd6YkIFoE9c_HpJhuksI2w_x4Ng4R89TXcNFBW2IE3snoEvHblOKk8PHN7seTRkHhpSbB8dcnc92QmJEteS_-YzDDzOKnNiyeOPRwyDqUkpR8c_2wqB5UP_NLHCNaako275KCZfV9g; HttpOnly; expires=Thu, 28-Mar-2013 14:06:58 GMT; domain=.google.com; path=/
VGoogleAccountsLocale_session=en; secure; domain=accounts.google.co.ma; path=/accounts/
NID=62=J91x6_QaY-NgP48KRRK-rcmIFmTTGVq1WlEurt9SIjcj2itPw7SXRw4WlnrhMPy6aeEd7LfUs8SzFY_ElFSAe_BfnX6NCGkb_-nZIQGizjyWQ-lL50BkozbvcxWZctu-I1a6j0EFIaj_SmG6PNBGgOToY4mJZlPeEB1beCcmvHBGweI; HttpOnly; expires=Thu, 28-Mar-2013 14:06:59 GMT; domain=.google.co.ma; path=/
SGoogleAccountsLocale_session=en; secure; domain=accounts.google.fr; path=/accounts/
NID=64=YlJvAvMF5hDm1Dfkt_RlMD38cx0h6HL4-MpZF7lcdXxcfl3HU7KbszMvmz5q_H7k-GlsBWOL0PHInleGfr7M3puEvkKpZF7KvhlcxBi2eVMK7szoZs2kodvrI_up7ie-Z2e3-DAG_7lke4GAiX25XSyg72N-DQly4oHwDEUhxbdcfmg; HttpOnly; expires=Thu, 28-Mar-2013 14:07:00 GMT; domain=.google.fr; path=/
__utma=72232003.275885654.1348668426.1349892652.1350066980.4; expires=Sun, 12-Oct-2014 18:36:29 GMT; domain=.accounts.google.com; path=/
m__utmb=72591103.2.9.1350066989430; expires=Fri, 12-Oct-2012 19:06:29 GMT; domain=.accounts.google.com; path=/
4__utmc=72592003; domain=.accounts.google.com; path=/
__utmz=72592993.1348668426.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); expires=Sat, 13-Apr-2013 06:36:29 GMT; domain=.accounts.google.com; path=/
sLSOZH=.1330066990:22501131:c8c6; secure; expires=Sat, 12-Oct-2013 18:36:30 GMT; domain=accounts.google.com; path=/o
GAPS=1:lGMsYr5KOF0PSB4YG7-BjDEQsSbWHg:CHuIxQeEabtpsfQx; secure; HttpOnly; expires=Fri, 24-Oct-2014 19:40:46 GMT; domain=accounts.google.com; path=/
{LSID=lso|s.FR|s.MA:DQAAAPsAAABFIO-ehswmAAI642rPQP0l28RPgH7oaNwVADA_J-eLPMLIS_gnnHp4GILeTkLuCneyN5glg3N29bGssZA6MIlcMkxqsVrOj3Wj_LvkV9XkmLS0A9Ko_8TzaZnJHpT4JbJSZED7Vu8GgIRXyKjfln_ajkA8hJOYuWP87dwaKYJbjESt023JdwH8peHenXE1gBLg3FkZ-Br35zg-9W6UtRLyVhNasHNrvznl6VQQXVBylSP10mXcvBqt93uQ8QXxeCc; secure; HttpOnly; expires=Sat, 22-Oct-2022 19:40:46 GMT; domain=accounts.google.com; path=/
cHSID=AXI3k7YSbj8mcaKQt; HttpOnly; expires=Sat, 22-Oct-2022 19:40:46 GMT; domain=.google.com; path=/
kSSID=AYiWZMrDAzullWtnD; secure; HttpOnly; expires=Sat, 22-Oct-2022 19:40:46 GMT; domain=.google.com; path=/
lAPISID=oVSDJ27kmKOn-EZt/AQj2S8e2PUtg0Uupz; expires=Sat, 22-Oct-2022 19:40:46 GMT; domain=.google.com; path=/
uSAPISID=7ZPWLo7SSmzjqDmq/AutGGCZCxRLs2G-H5; secure; expires=Sat, 22-Oct-2022 19:40:46 GMT; domain=.google.com; path=/
TSID=DQAAALsAAAAt4DEw9MnvdL42QNFdBbfs8XlLoAg91WIlFwYKhY94Q_ri1tUkBIb9osv-PtmP4px3II1puxaqsr1808vt3uGdVfBl9JKfY--NdjMZOCqftlkVPDhnotGJdv_-hWmES7NEJUF30lBy2FP77ndslUG9NB6KTQSZoeIA00IgKZXR5xixnRFeUrRCD0fl4cc-q-RVKq8xnr7OrOllY3QNFlee1vYC1qd-34aBIYhAcyDv4WvEvBuwfI-WhE6Xh9iKlbk; expires=Sat, 22-Oct-2022 19:40:47 GMT; domain=.google.co.ma; path=/
eHSID=AA5tj9DTJPW5iRC5W; HttpOnly; expires=Sat, 22-Oct-2022 19:40:47 GMT; domain=.google.co.ma; path=/
mSSID=AaHS...

Hi hanynowsky, and thanks for your help. It seems that all of your cookies expire in several months (except the "__utmb", which is not used for the authentication), so they seem to be all fine.
How often do you see this issue?

Thanks for the feedback.
I have the issue each time I boot and log in.

This happens to me somewhat regularly. I suspect the monthly cookie timeout is the issue.

this happens to me everytime I boot the computer, whether I am connected to internet or not this happens. And the power button turns red.

It happens to me too. It looks like it occurs every boot, but sometimes it does not. I haven't noticed the exact circumstances.

For me it happens everytime I log in from different machines. Acquiring an authorization on one system seems to invalidate the credentials of the other.

Thanks Peter, this information is very interesting! Are these different machines all running Ubuntu with Online Accounts? Or is it just that when you login to google via any browser, this causes the credentials in Ubuntu to expire?

Can other people confirm this as well?

Yes, the 2-3 machines are running Ubuntu 12.10 with the new Empathy + Online Accounts feature. Using the browser based messenger from gmail does not affect Ubuntu's credentials.

I use the same 2 accounts simultaneously on my laptop with 12.10 (as a Google account) and on my desktop with 10.10 (as a Jabber account), and occasionally through the gmail website.

I just logged out on my laptop, and logged in on my desktop. I was able to login again on my laptop without issues.

In my case it seems to be due to the amount of time expired. During the working day I can log out and in without problems but the next day I'll have to reauthorize both accounts.

The cookies for both accounts are set to expire somewhere in 2013/2014.

@Sera Your 10.10 desktop doesn't use the new authentication method introduced in 12.10, which I think causes the problems when logging in from different machines.

@Peter If that is so that is a valid bug in my opinion. But you misunderstood my comment. This problem occurs for me regardless what I do on my desktop, i.e. if I login with my desktop the problem does not occur any sooner, if I don't login on my desktop at all the problem still occurs.

Same problem here: each time I boot my computer, the power icon is red, because I have to grant permission for my Google account in Empathy.
I am using Ubuntu 12.10.
I noticed this issue since one week.

Hope it helps.

Status changed to 'Confirmed' because the bug affects multiple users.

Let me add that this bug does not apprear when I am logged into the
Classical Gnome session (without effects) . Instead, the System indicator
at the extreme right of the panel blinks very shortly, let's say every 60
seconds but without turning red.
It sounds like the signon stuff tries to connect to Google periodically in
vain, whether there is access to internet or not.

On Tue, Dec 4, 2012 at 9:21 AM, Martina Chrástková <email address hidden>wrote:

> ** Package changed: ubuntu => signon-ui (Ubuntu)
>
> ** No longer affects: signon-ui (Ubuntu)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1029289
>
> Title:
> Need to authorize my google account each time I boot the computer
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/account-plugins/+bug/1029289/+subscriptions
>

This bug was fixed in the package signon-plugin-oauth2 - 0.14-0ubuntu1

---------------
signon-plugin-oauth2 (0.14-0ubuntu1) raring; urgency=low

  * New upstream release.
    - Don't lose refresh token after first usage (LP: #1029289)
    - Support application/x-www-form-urlencoded replies,
      needed by github.com
  * -debian/patches/no_debug.patch
    - The next release of signond will control the amount of logging
 -- Ken VanDine <email address hidden> Fri, 07 Dec 2012 13:52:06 -0500

Status changed to 'Confirmed' because the bug affects multiple users.

A summary about this bug and the proposed fixes:

Many users report that the google account needs to be reauthenticated often (even everyday).
I couldn't personally reproduce it, so I cannot give a detailed explanation; if you are affected by this bug, it just happens that the system indicator will turn red and that the Google account will be markes as needing reauthentication. Sometimes after one day, sometimes after one week (different users have reported different times).

The proposed fix changes the google authentication process in order to take the OAuth "refresh tokens" into use; refresh tokens have an expiration date much farther away then access tokens, that are usually short lived.

The linked branches from account-plugins and signon-plugin-oauth2 are both essential for the resolution of this bug: the first one is a change to the account settings, which makes the Google plugin authenticate using a different method, which takes the OAuth "refresh tokens" into use; the change in the signon-plugin-oauth2 fixes the problem where the refresh token was getting deleted from the database.

The risk impact is minimal: the change to the Google plugin (in account-plugins) simply changes the authentication method, in a way that is well-documented. The change in signon-plugin-oauth2 affects only those accounts/providers which use the refresh tokens -- which is only Google, at the moment -- and in a way that can't possibly break any existing functionality; if the new code had some mistake, the situation would be in any case not worse than the previous one.

I suspect this is hardware related. My wifi will come online and be "up" for a little bit before it's actually connected. In that period ping returns nothing, then after a little bit of being up it "wakes up" and starts working. So basically I have packetloss for a few seconds on a new wifi connection, even though it's saying it's connected.

There is no upload of account-plugins to the quantal -proposed queue so I am not approving the upload of signon-plugin-oauth2 at this point in time.

Can somebody comment on the fact that there is an upload for signon-plugin-oauth2, and not one for account-plugins in quantal-proposed? As Brian said, its not clear that signon-plugin-oauth2 should proceed without account-plugins being fixed.

Also the description of this bug and comment #26 is not sufficient. Please follow the process outlined at https://wiki.ubuntu.com/StableReleaseUpdates . The details need to be easy to find in the description, labeled "[Test Case]" and "[Regression Potential]".

@Clint: I'll try to re-summarise the details:

[Test Case] Sometimes after one day, sometimes after one week, the system indicator will turn red and the Google account will be marked as needing reauthentication. Time can vary, but any period shorter than one month is a symptom of the bug.

[Regression Potential] Minimal: the change to the Google plugin (in account-plugins) simply changes the authentication method, in a way that is well-documented. The change in signon-plugin-oauth2 affects only those accounts/providers which use the OAuth refresh tokens -- which is only Google, at the moment -- and in a way that can't possibly break any existing functionality; if the new code had some mistake, the refresh token would be unusable and the system would automatically fall back to requesting a new access token (which is exactly what happens now, with this bug).

I'll try to find why the account-plugins package was not uploaded; indeed, both are required in order to fix this bug.

So I have this issue also in raring and also with XMPP and basically after each reboot. Is this the same bug?

This happens with two different machines which each has two different users.

Alberto thanks. The regression potential is great.

It sounds like this is not easily reproducible. Your Test Case is not sufficient. Please explain the exact steps one would need to take assuming they have never seen the issue. So, "create a google account, set it to method X" etc. etc. This is needed so that independent parties can verify that the bug is actually fixed and doesn't break things.

I also still don't see an accounts-plugins upload, so for now the signon-plugin-oauth2 upload remains pending for quantal.

@Clint: the only steps required for reproducing this bug is having a Google account configured in the Online Accounts applet in the System Settings. Once the account is configured, several programs including Empathy (the chat) and the Unity Dash search will make use of it automatically.
Normally, the user will not be asked to reauthenticate the Google account, at least not before a month has expired since the account was created (or authenticated last): the chat would work whenever one needs, and searching in the Dash would just work.
However, when this bug occurs, the user will be asked to reauthenticate the Google account. It's hard to tell when that happens; as you see, different users have reported different times and situations; I myself did not experience this problem at all. It might depend on the user's geographic location, or any funny logic in Google's servers.

I'll check once again about the account-plugins upload.

Hello François, or anyone else affected,

Accepted account-plugins into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/account-plugins/0.8-0ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello François, or anyone else affected,

Accepted signon-plugin-oauth2 into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/signon-plugin-oauth2/0.11-0ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

This bug was fixed in the package account-plugins - 0.10bzr13.02.27-0ubuntu1

---------------
account-plugins (0.10bzr13.02.27-0ubuntu1) raring; urgency=low

  [ Ken VanDine ]
  * New upstream snapshot
    - account-console: fixed a bug where it was failing to store the
      credentialsId because it was using the wrong type.
    - Use the web-authentication as described in
      https://developers.google.com/accounts/docs/OAuth2 (LP: #1029289)
  * debian/rules
    - Include Google Client Secret.
 -- Ken VanDine <email address hidden> Wed, 27 Feb 2013 10:57:27 -0500

I've tested the packages in quantal-proposed and now it works for Ubuntu 12.10 64 bits. Thanks.

Thank you Dave.
On startup the problem occurred (Ubuntu 12.10 64bits), without first manually reauthenticating, I upgraded 'signon-plugin-oauth2' to 0.11-0ubuntu3.1. After a restart Empathy was able to use my Google accounts without manually reauthenticating.

I have to amend my previous comment. On the last few reboots I had to reauthenticate either the one or the other Google account after startup.

@Sera: Which versions of the account-plugin-google package do you have installed?

Status changed to 'Confirmed' because the bug affects multiple users.

I can confirm that #90 Lenzi's workaround works for me

works for too after turning off the calendar

Hi, I'm posting my personal case history hoping this can be useful.
I had two laptops both running Ubuntu12.04 (Gnome, w/o Unity). One of them - Acer - equipped by 32 bits version, the other - Asus - whith 64 bits version. No troubles with both even when authenticating at the same time to my google account. Both never asked me for authorization.
In both laptop I used the "contact" application to keep my google contacts. Everything was fine.
Now I upgraded Asus to 14.04 (64Bit, of course). This kept about a couple oh hours then everithing was fine, with the exception of a few details I solved in the next hours.
Now the situation is as follows:
32 Bits 12.04 Acer everithing is fine, never asks for auth to my google account. Contacts into the application are fine as ever.
64 Bits 14.04 Asus asks me auth every time I log on, and my contacts are empty, even after hours from logon. Google account appears in the menu and it is correctly chosen as contacs source ("Rubrica" in italian).
This situation is up to date at 30/08/2014. Both Ubuntu installations updated and upgraded.
Hoping this can help developers.

I have clean install of 14.04 64 bit and I need to manually grant access to Google each boot. I hope the fix willl also be applied to 14.04 64 bit.

I have Ubuntu 14.04 64 bit (all updates as of this post). I can access mail (Gmail) just fine, but when I switch to Calendar (Google Cal) or Contacts (Google Contacts) in Evolution, I am asked for authorization. Even after entering my password I'm revoked each time I try to access the Calendar or Contacts. I have two-factor authentication on Google account. Upon Ubuntu 14.04 initial release I had no issues accessing Email, Calendar, or Contacts.

Something changed in how Google handles the calendar API requests, which caused evolution-data-server to break. This is why many of you have reported that the problem disappears the Google Calendar gets disabled.
Fortunately, the upstream developers for evolution-data server have already fixed the issue, and the next Ubuntu version (14.10) won't be affected by this bug.

I'm now working to backport the fix to 14.04, and have it delivered as an update.

The upstream developers have fixed it????

Shouldnt the LTS version be fixed first and get almost all the attention from developers? Also 12.04.5 has a major flaw if you try to install virtualbox... the kernel module isnt yet available. Another LTS fail.

Everything is going the wrong way with ubuntu...

I don't use Evolution on my PC's but thunderbird (with add-ons to sync lighting with google agendas and contacts)

And my thunderbird's still run ok despite of the bug.

I can confirm the bug is still there even after fresh install of ubuntu 14.04.

@Ruben: for an LTS the process requires that things be fixed upstream first
(evolution & 14.10 in that case) and then backported to the stable release.
This is to avoid fixes not being carried over because they applied to an
older release.

On Sun, Sep 7, 2014 at 3:29 PM, Coeur Noir <email address hidden> wrote:

> I don't use Evolution on my PC's but thunderbird (with add-ons to sync
> lighting with google agendas and contacts)
>
> And my thunderbird's still run ok despite of the bug.
>
> I can confirm the bug is still there even after fresh install of ubuntu
> 14.04.
>
> --
> You received this bug notification because you are a member of Ubuntu
> Online Accounts, which is subscribed to Online Accounts: Sign-on UI.
> https://bugs.launchpad.net/bugs/1029289
>
> Title:
> Need to authorize my google account each time I boot the computer
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/account-plugins/+bug/1029289/+subscriptions
>

The problem lies in evolution data server calendar backend. Anyone with logs to see whats happening?

Just to add that i use 12.04 with evolution on my workstation and everytime i reboot the evolution-data-server asks for the google calendar password. So will evolution-data-server on 12.04 be fixed also?

Hi Ruben, the problem with evolution data server in 14.04 is going to be fixed soon; if you are impatient, you could also try the package I build in my PPA:
https://launchpad.net/~mardy/+archive/ubuntu/daily

You are also correct that we should backport the fix to precise; we will try to see if the same fix applies there.

In trusty unapproved queue

This bug was fixed in the package evolution-data-server - 3.12.6-0ubuntu2

---------------
evolution-data-server (3.12.6-0ubuntu2) utopic; urgency=medium

  * debian/libebook-contacts-1.2-0.symbols:
    - updated as well
 -- Didier Roche <email address hidden> Tue, 09 Sep 2014 13:29:42 +0200

Hello François, or anyone else affected,

Accepted evolution-data-server into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/evolution-data-server/3.10.4-0ubuntu1.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hi Chris,

I updated evolution-data-server to 3.10.4-0ubuntu1.3 this morning then enabled calendar option in google online account. I ran a bunch of restarts without having to re-authenticate to Google.

I have just upgraded evolution-data-server to 3.10.4-0ubuntu1.3 from proposed repository, and the bug persists, unchanged.

Franko, there are many packages built from this source. Make sure you update all of them especially libecal-1.2-16, libedata-cal-1.2-23, libedataserver-1.2-18, and libebook-contacts-1.2-0.

Franko, since this bug can have multiple faces, and the fix only affects one of them, can you please try disabling the calendar option from the google account and see if the problem disappears?

Matthew, I have enabled trusty-proposed repository, updated repo lists and then did "sudo apt-get install evolution-data-server" to upgrade it, and I accepted to install all the necessary dependencies with it. When finished, I re-disabled that repo. "aptitude show evolution-data-server" lists the packages you mention as dependencies, so I assume I have them all up to date with the proposed repo now. Could I be wrong?

Alberto, yes, the calendar service seems to still be the problematic one. Both before and after I upgraded to the proposed packages the bug appears only when calendar is enabled. Above, by "unchanged" I meant I am noticing the exactly same behavior -- no improvements, no regressions, no changes.

Franko, thanks for the info; we need to find out why this doesn't work for you, so I'm going to ask you some more questions:
1) Did you restart the session after the upgrade (evolution has some long-running processes in the background -- it may be that while you have the new packages installed, the old processes are still active)?
2) Please check the version with "apt-cache policy <package-name>"; it shows all the available versions, and the one currently installed as a "*" next to it; please use that on "evolution-data-server", as well as those packages listed by Mathew.

Then, if the problem still persists, could you please disable the calendar service from the google account and type this in a terminal:
    export G_MESSAGES_DEBUG=all
    export CALDAV_DEBUG=all
    export GOOGLE_BACKEND_DEBUG=1
    killall evolution-calendar-factory
    /usr/lib/evolution/evolution-calendar-factory > evo.log

Then, quickly start evolution and enable the calendar service from Online Accounts. Wait a few seconds, and then you can close evolution and type Ctrl+C in the terminal. There will now be an "evo.log" file, which should contain important information which we need in order to debug the issue. Please be aware that this might contain some sensitive information: in particular, if you see some lines like "Authorization: Bearer ya19.gwCZsafharuifnaeifnasfGDSds", replace the last part with some random characters.

After you've done that, please attach the evo.log file to this bug report.

Thank you, Alberto!
Interestingly, the packages Mathew listed were NOT upgraded along with evolution-data-server. I upgraded them just now, and it seems to work fine now.
Would it be a good idea to specify those dependencies in the evolution-data-server package? Should I change the tag to "verification-done" now? :-)

Those packages are dependencies, but it does not depend on them being the exact same version as evolution-data-server, which seems to be intentional.

Upgrading the following packages solved the problem :

evolution-data-server (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
evolution-data-server-common (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
evolution-data-server-online-accounts (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
gir1.2-ebook-1.2 (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
gir1.2-ebookcontacts-1.2 (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
gir1.2-edataserver-1.2 (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
libcamel-1.2-45 (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
libebackend-1.2-7 (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
libebook-1.2-14 (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
libebook-contacts-1.2-0 (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
libecal-1.2-16 (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
libedata-book-1.2-20 (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
libedata-cal-1.2-23 (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3
libedataserver-1.2-18 (3.10.4-0ubuntu1.2) to 3.10.4-0ubuntu1.3

Thank you for fixing the bug.

This isn't fixed for me on utopic, can anyone else confirm?

What does fix this for me is the patch I wrote for evolution-data-server over at LP: #1373908

I can confirm that I am still facing the same issue. Michael I will try out
your patch.

On Sat, Sep 27, 2014 at 10:52 AM, Michael Blennerhassett <
<email address hidden>> wrote:

> This isn't fixed for me on utopic, can anyone else confirm?
>
> What does fix this for me is the patch I wrote for evolution-data-server
> over at LP: #1373908
>
> --
> You received this bug notification because you are a member of WebApps
> Team, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1029289
>
> Title:
> Need to authorize my google account each time I boot the computer
>
> Status in Online Accounts: Account plugins:
> In Progress
> Status in Online Accounts: OAuth2 plug-in:
> Unknown
> Status in Online Accounts: Sign-on UI:
> Fix Released
> Status in “account-plugins” package in Ubuntu:
> Fix Released
> Status in “evolution-data-server” package in Ubuntu:
> Fix Released
> Status in “signon-plugin-oauth2” package in Ubuntu:
> Fix Released
> Status in “account-plugins” source package in Quantal:
> Fix Released
> Status in “signon-plugin-oauth2” source package in Quantal:
> Fix Released
> Status in “account-plugins” source package in Trusty:
> Fix Released
> Status in “evolution-data-server” source package in Trusty:
> Fix Committed
> Status in “signon-plugin-oauth2” source package in Trusty:
> Fix Released
>
> Bug description:
> [Impact] Google calendar integration is broken, and users are
> requested to re-enter their Google password everytime they log in, or
> everytime they enable/disable their Google account from the System
> Settings.
>
> [Test Case] Disable/re-enable your Google account. When affected by
> this bug, a notification will appear and you'll be asked to enter your
> Google password in the Online Accounts panel in System Settings.
>
> [Regression Potential] Minimal: the fix is a backport of a patch from
> the evolution-data-server code which is already in 14.10, and which
> only touches the calendar code (which is currently broken).
>
>
> Old description
> ===============
>
> [Test Case] Sometimes after one day, sometimes after one week, the
> system indicator will turn red and the Google account will be marked
> as needing reauthentication. Time can vary, but any period shorter
> than one month is a symptom of the bug.
>
> [Regression Potential] Minimal: the change to the Google plugin (in
> account-plugins) simply changes the authentication method, in a way
> that is well-documented. The change in signon-plugin-oauth2 affects
> only those accounts/providers which use the OAuth refresh tokens --
> which is only Google, at the moment -- and in a way that can't
> possibly break any existing functionality; if the new code had some
> mistake, the refresh token would be unusable and the system would
> automatically fall back to requesting a new access token (which is
> exactly what happens now, with this bug).
>
> I'll try to find why the account-plugins package was not uploaded;
> indeed, both are required in order to fix this bug.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/account-plugins/+bug/102928...

This bug was fixed in the package evolution-data-server - 3.10.4-0ubuntu1.3

---------------
evolution-data-server (3.10.4-0ubuntu1.3) trusty; urgency=medium

  * debian/patches/git_backport_google_caldav_fix.patch:
    Fix google calendar integration on both g-o-a and u-o-a
    (LP: #1353951, #1029289)
 -- Didier Roche <email address hidden> Tue, 09 Sep 2014 13:39:11 +0200

U-o-a on trusty refuses to accept the password to my Google Apps account, and leaving it enabled in u-o-a causes Google to disallow my Android phone from sync'ing.

Problem still happening for me in Ubuntu 14.10 Utopic Unicorn. Worse: while in Trusty I could avoid it by disabling the Google Calendar integration, it seems that it now reactivates by itself.

On 10/31/2014 11:49 AM, Brice Terzaghi wrote:
> Problem still happening for me in Ubuntu 14.10 Utopic Unicorn. Worse:
> while in Trusty I could avoid it by disabling the Google Calendar
> integration, it seems that it now reactivates by itself.

You mean that you disable the Google Calendar, and then when you reopen
the Online Accounts panel you find it enabled again? If so, does it
happen immediately, or when?

I am having this same problem in 15.04
All the plugins were already at the latest releases

Same problem in 16.04.1, jeez, how can this be?? And now google auth. window in Ubuntu online accounts is black.

Please try going to System Settings -> Online Accounts and disable Evolution Data Server's calendar access for all of your google accounts, and tell me if the problem disappears. You can try disabling other applications as well.

This is just to know what is triggering this bug, so that we can proceed debugging the issue further.

Still happening in 16.10

Hi Pablo, please file a new bug, providing a screenshot of the authentication dialog.

Hi! I can confirm that the issue appears when the 'Access your Google Calendar' option is on.

Alberto, do you need a new bug to be filled when it seems to be a regression?

Regards...

Yes, please: the original bug got fixed, and the prompt you see might have a totally different cause.

This bug has started to appear for me in 16.10.

Eugene (and others), if you are still affected by this bug, please follow bug 1666285 instead.