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?

@Alberto: I've enabled the quantal-proposed repository and installed account-plugin-google-0.8-0ubuntu2.1

@Sera; could you please install the account-plugin-tools package (if it's not installed already) and run this command from a terminal

account-console list
account-console show <google-account-number>

where <google-account-number> is the numeric ID of the google account, as returned by the "list" command, and paste the result in a comment here?

0.11-0ubuntu3.1 here
I don't have any disconnection, and I have been using it for more than a week. And I don't have any problem so far ! To me, it's working fine, thanks for the fix.

@Alberto; below is the output of the requested commands for both Google accounts. I've anonimized the data, let me know if I've redacted too much (or too little).

~
seraph $ account-console list

** (process:4311): CRITICAL **: Unsupported type guint32

** (process:4311): CRITICAL **: Unsupported type guint32

** (process:4311): CRITICAL **: Unsupported type guint32

** (process:4311): CRITICAL **: Unsupported type guint32

** (process:4311): CRITICAL **: Unsupported type guint32

** (process:4311): CRITICAL **: Unsupported type guint32

** (process:4311): CRITICAL **: Unsupported type guint32
account: id 8, enabled, provider: google
account: id 7, enabled, provider: google
account: id 6, disabled, provider: jabber
account: id 5, enabled, provider: windows-live
account: id 4, enabled, provider: icq
account: id 3, enabled, provider: local-xmpp
account: id 2, disabled, provider: jabber
~
seraph $ account-console show 8
account: id 8, enabled, provider: google
  Global settings:
    CredentialsId: 9 (<class 'int'>)
    auth/mechanism: web_server (<class 'str'>)
    auth/method: oauth2 (<class 'str'>)
    auth/oauth2/user_agent/AuthPath: o/oauth2/auth (<class 'str'>)
    auth/oauth2/user_agent/ClientId: <id> (<class 'str'>)
    auth/oauth2/user_agent/Host: accounts.google.com (<class 'str'>)
    auth/oauth2/user_agent/RedirectUri: https://wiki.ubuntu.com/ (<class 'str'>)
    auth/oauth2/user_agent/ResponseType: token (<class 'str'>)
    auth/oauth2/user_agent/Scope: ['https://docs.google.com/feeds/', 'https://www.googleapis.com/auth/googletalk', 'https://www.googleapis.com/auth/userinfo.email', 'https://www.googleapis.com/auth/userinfo.profile', 'https://picasaweb.google.com/data/'] (<class 'list'>)
    auth/oauth2/user_agent/TokenPath: o/oauth2/token (<class 'str'>)
    auth/oauth2/web_server/AllowedSchemes: ['https', 'http'] (<class 'list'>)
    auth/oauth2/web_server/AuthPath: o/oauth2/auth (<class 'str'>)
    auth/oauth2/web_server/ClientId: <id> (<class 'str'>)
    auth/oauth2/web_server/ClientSecret: <secret> (<class 'str'>)
    auth/oauth2/web_server/Host: accounts.google.com (<class 'str'>)
    auth/oauth2/web_server/RedirectUri: https://wiki.ubuntu.com/ (<class 'str'>)
    auth/oauth2/web_server/ResponseType: code&access_type=offline (<class 'str'>)
    auth/oauth2/web_server/Scope: ['https://docs.google.com/feeds/', 'https://www.googleapis.com/auth/googletalk', 'https://www.googleapis.com/auth/userinfo.email', 'https://www.googleapis.com/auth/userinfo.profile', 'https://picasaweb.google.com/data/'] (<class 'list'>)
    auth/oauth2/web_server/TokenPath: o/oauth2/token (<class 'str'>)
    enabled: True (<class 'bool'>)
    name: <name/email> (<class 'str'>)
  Settings for google-docs
    auth/google/ClientLogin/Service: writely (<class 'str'>)
    auth/google/ClientLogin/Source: Ubuntu-documents-1.0 (<class 'str'>)
    auth/oauth2/user_agent/Scope: ['https://docs.google.com/feeds/'] (<class 'list'>)
    enabled: True (<class 'bool'>)
  Settings for google-im
    enabled: True (<class 'bool'>)
    telepathy/AvatarMime: (<class 'str'>)
    telepathy/HasBeenOnline: true (<class 'str'>)
    telepathy/Nickname: <Nick> (<class 'str'>)
    t...

0.11-0ubuntu3.1 does not work me.

On Fri, Mar 8, 2013 at 12:50 PM, Sera <email address hidden> wrote:

> @Alberto; below is the output of the requested commands for both Google
> accounts. I've anonimized the data, let me know if I've redacted too
> much (or too little).
>
> ~
> seraph $ account-console list
>
> ** (process:4311): CRITICAL **: Unsupported type guint32
>
> ** (process:4311): CRITICAL **: Unsupported type guint32
>
> ** (process:4311): CRITICAL **: Unsupported type guint32
>
> ** (process:4311): CRITICAL **: Unsupported type guint32
>
> ** (process:4311): CRITICAL **: Unsupported type guint32
>
> ** (process:4311): CRITICAL **: Unsupported type guint32
>
> ** (process:4311): CRITICAL **: Unsupported type guint32
> account: id 8, enabled, provider: google
> account: id 7, enabled, provider: google
> account: id 6, disabled, provider: jabber
> account: id 5, enabled, provider: windows-live
> account: id 4, enabled, provider: icq
> account: id 3, enabled, provider: local-xmpp
> account: id 2, disabled, provider: jabber
> ~
> seraph $ account-console show 8
> account: id 8, enabled, provider: google
> Global settings:
> CredentialsId: 9 (<class 'int'>)
> auth/mechanism: web_server (<class 'str'>)
> auth/method: oauth2 (<class 'str'>)
> auth/oauth2/user_agent/AuthPath: o/oauth2/auth (<class 'str'>)
> auth/oauth2/user_agent/ClientId: <id> (<class 'str'>)
> auth/oauth2/user_agent/Host: accounts.google.com (<class 'str'>)
> auth/oauth2/user_agent/RedirectUri: https://wiki.ubuntu.com/ (<class
> 'str'>)
> auth/oauth2/user_agent/ResponseType: token (<class 'str'>)
> auth/oauth2/user_agent/Scope: ['https://docs.google.com/feeds/', '
> https://www.googleapis.com/auth/googletalk', '
> https://www.googleapis.com/auth/userinfo.email', '
> https://www.googleapis.com/auth/userinfo.profile', '
> https://picasaweb.google.com/data/'] (<class 'list'>)
> auth/oauth2/user_agent/TokenPath: o/oauth2/token (<class 'str'>)
> auth/oauth2/web_server/AllowedSchemes: ['https', 'http'] (<class
> 'list'>)
> auth/oauth2/web_server/AuthPath: o/oauth2/auth (<class 'str'>)
> auth/oauth2/web_server/ClientId: <id> (<class 'str'>)
> auth/oauth2/web_server/ClientSecret: <secret> (<class 'str'>)
> auth/oauth2/web_server/Host: accounts.google.com (<class 'str'>)
> auth/oauth2/web_server/RedirectUri: https://wiki.ubuntu.com/ (<class
> 'str'>)
> auth/oauth2/web_server/ResponseType: code&access_type=offline (<class
> 'str'>)
> auth/oauth2/web_server/Scope: ['https://docs.google.com/feeds/', '
> https://www.googleapis.com/auth/googletalk', '
> https://www.googleapis.com/auth/userinfo.email', '
> https://www.googleapis.com/auth/userinfo.profile', '
> https://picasaweb.google.com/data/'] (<class 'list'>)
> auth/oauth2/web_server/TokenPath: o/oauth2/token (<class 'str'>)
> enabled: True (<class 'bool'>)
> name: <name/email> (<class 'str'>)
> Settings for google-docs
> auth/google/ClientLogin/Service: writely (<class 'str'>)
> auth/google/ClientLogin/Source: Ubuntu-documents-1.0 (<class 'str'>)
> auth/oauth2/user_agent/Scope: ['https://docs.google.com/feeds/']
> (<class '...

@Alberto, for the last two days this problem has not occurred. Maybe it needed an extra few reboots and reauthentications to 'stick'?

@Sera: I think that one reauthentication per account should be enough. Did you have to reauthenticate the accounts more than that?
Rebooting once might also be necessary (with the new signond from raring this won't be necessary anymore) -- it all depends on whether the old authentication plugin is still loaded, so indeed it's safer to reboot (or just "killall signond").

@Alberto After the upgrade, I disconnected the Google accounts, rebooted and reauthenticated them. After that I had to reauthenticate them two times each after subsequent reboots.

I still have this problem in 13.04, exactly the same as in my 12.10 installation. My google accounts needs to be granted access every time I boot Ubuntu.

This fix has improved the situation, however google accounts are still more prone to require authentication than the others, but it is much better. I marked this as verification-done.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package account-plugins - 0.8-0ubuntu2.1

---------------
account-plugins (0.8-0ubuntu2.1) quantal-proposed; urgency=low

  * debian/patches/lp_1029289.patch
    - Use the web-authentication as described in
      https://developers.google.com/accounts/docs/OAuth2 (LP: #1029289)
  * debian/rules
    - Include Google Client Secret.
 -- Robert Bruce Park <email address hidden> Tue, 26 Feb 2013 09:23:22 -0800

This bug was fixed in the package signon-plugin-oauth2 - 0.11-0ubuntu3.1

---------------
signon-plugin-oauth2 (0.11-0ubuntu3.1) quantal-proposed; urgency=low

  * debian/patches/lp1029289.patch
    - Don't lose refresh token after first usage (LP: #1029289)
 -- Ken VanDine <email address hidden> Fri, 07 Dec 2012 13:58:21 -0500

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.2 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!

I'm running an uptodate Raring, and I have this issue at every boot. I checked:

rene@trololo:~$ dpkg-query -s signon-plugin-oauth2
Package: signon-plugin-oauth2
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 210
Maintainer: Ubuntu Desktop Team <email address hidden>
Architecture: amd64
Version: 0.15-0ubuntu1
Depends: libc6 (>= 2.2.5), libqjson0 (>= 0.7.1), libqt4-network (>= 4:4.5.3), libqtcore4 (>= 4:4.7.0~beta1), libstdc++6 (>= 4.1.1), signon-ui
Description: Single Signon oauth2 plugin
 Oauth2 plugin for the Single Signon framework
Homepage: http://code.google.com/p/accounts-sso/

I'm uncertain about the version: does this contain the fix? It appears it would not. Anyring I can do to gather info, let me know.

Hi Rene, your version of the signon-plugin-oauth2 definitely contains the fix. What about account-plugin-google?

Also, did you try deleting the account and re-creating it? That might help as well.

No joy:
rene@trololo:~$ dpkg-query -s account-plugin-google
Package: account-plugin-google
Status: install ok installed
Priority: optional
Section: gnome
Installed-Size: 56
Maintainer: Ubuntu Desktop Team <email address hidden>
Architecture: all
Source: account-plugins
Version: 0.11daily13.06.06-0ubuntu1~raring1
Depends: libaccount-plugin-google, signon-keyring-extension, signon-plugin-oauth2, unity-asset-pool (>> 0.8.24daily12.12.05-0ubuntu1)
Conffiles:
 /etc/signon-ui/webkit-options.d/accounts.google.com.conf 3e4d5858d7818564f15e6906d10ef487
Description: GNOME Control Center account plugin for single signon
 GNOME Control Center account plugins for single signon
Homepage: https://launchpad.net/account-plugins

I deleted the google account, rebooted, added the google account. Rebooted, and the error came back up.

Some probably superfluous irrelevant info: I'm using 2-factor auth (but reauthorizing the account only requires my password, not a token. Makes sense) Also, in syslog:

Jun 17 13:39:38 trololo/192.168.20.20 signond[3733]: ../../../../src/signond/signondaemon.cpp 360 init Failed to SUID root. Secure storage will not be available.

I cannot determine whether this is relevant or not. I haven't seen this error connected to this problem yet.

I released 0.8-0ubuntu2.2 to quantal by mistake before noticing that this bug was still verification-needed. However, I think that was artificial; 0.8-0ubuntu2.1 had already been copied to quantal-updates and was the version containing the fix for this bug; it's just that the .changes file for 0.8-0ubuntu2.2 was generated with respect to 0.8-0ubuntu2.

If this release was a problem, please let me know on IRC and we'll see what we can do about it.

Hi,

I'm running raring amd64 up to date, and the issue started a couple od days ago. I can add that I think the issue started after I enabled GoogleTalk app in an android device. So, seems to be related to app connection from a different computer. I still have to do some testing to reproduce the normal behavior when the android device is not online.

Hope this helps.

Thanks,
Felipe.

Hi,

Ok. I disconnected my android device, then rebooted my ubuntu system and Empathy looged in flawlessly. Then rebooted several times and everything kept working great. Then I reconnected my android device, rebooted my ubuntu system, and it still works great.

So... there was something related to the android connection, but seems to be fixed now.

Thanks,
Felipe.

Why is this fix not released for Raring? its quite major issue impacting the reliability of using Empathy for Google Talk.

I still see the problematic behaviour. I'm on Raring, with the following package versions:

account-plugin-google 0.11daily13.06.06-0ubuntu1~raring1
signon-plugin-oauth2 0.15-0ubuntu1

[Note: I'm using Gnome 3 via the PPA as detailed here : http://www.omgubuntu.co.uk/2013/04/gnome-3-8-ppa-for-ubuntu-gnome in case that makes any difference].

My Google account seemingly stays authenticated as long as I don't log out. If I log out (No matter if it's an hour after I logged in, or a week) then my credentials seem to be lost and I have to re-authenticate.

Is there anything I can do to debug this?

To everyone affected by this bug: please make sure that the "LoggingLevel=2" line in /etc/signond.conf is uncommented; if not, uncomment it, save the file (you must be root in order for this to work) and run "killall signond".
After that, if you manage to reproduce the bug again, please attach the /var/log/syslog file to this bug report just right after reproducing the issue.

Hi,

Please find attached a syslog output from a fresh boot, reproducing the problem. Hope this helps.

Kind reagrds,

René

I got this problem on every boot.

This starting happening again a couple days again. Attached is the syslog.

@Joachim: it's strange, it looks like some application is trying to authenticate with your google account by directly requesting the password. I wonder if that could be Empathy... Could you please run the command "account-console list" and then "account-console show <number>" where "<number>" is the number of the google account, and paste the result here (feel free to conceal your username, if you don't want it to be visible)?

@David: are you sure it's the google account the one asking for reauthentication? Looking at your logs, it would seem that it's facebook. Is that correct? If so, does it happen often? (it's normal that from time to time you have to reauthenticate the account, but not more once than a month -- actually, much more seldomly).

@Alberto: You are right. That was from Facebook, not Google. Today I booted up and my Google account is not authorized. Attached is the requested log.

Attached is the results of what you requested from Joachim. I don't know if my results are relevant to what you saw in his logs or not. Note that I changed my google username in the output to misterlizardsquad, which is not my real username. I also changed the values of the ClientSecrets.

I am attaching the syslog from my saucy system: the bug is still here. However, I encounter it at every login, even if not rebooting.
Follows the account-console show.

Here is the output of account-console show <id>

Thanks a lot, David and Damiano! Your cases seem to be different:

@Damiano: it looks like there is some application which asks to authenticate with Google using the plain password method, and that's what generating the error. In fact, from your logs I can see that the OAuth authentication went on successfully at 13:22:16 and at 13:22:54, but then at 13:23:00 the "password" method was used. Since you can reproduce the bug fairly easily, could you please try disabling evolution from the Online Accounts panel, logout and then in again? If you could try that for contacts, mail and calendar one at a time this would help us find the issue (I'd bet it's the calendar).
Anyway, when you click on the account to reauthenticate, does it directly show a form with username and password, or does it send you to the Google website?

@David: I know this is quite annoying, but do you think you can disable the Facebook and the MSN/Live accounts and try again? Since they all authenticate at the same time, and using the same method (Oauth), it's impossible to follow the logs. :-(
Also, how often does this happen?

@Alberto: I have no problem disabling the other services. This is on my
laptop, which is mostly a test machine anyways. I get this issue pretty
infrequently now so it may be a while until it happens again.

On Tue, Aug 20, 2013 at 8:06 AM, Alberto Mardegan <
<email address hidden>> wrote:

> Thanks a lot, David and Damiano! Your cases seem to be different:
>
> @Damiano: it looks like there is some application which asks to
> authenticate with Google using the plain password method, and that's what
> generating the error. In fact, from your logs I can see that the OAuth
> authentication went on successfully at 13:22:16 and at 13:22:54, but then
> at 13:23:00 the "password" method was used. Since you can reproduce the bug
> fairly easily, could you please try disabling evolution from the Online
> Accounts panel, logout and then in again? If you could try that for
> contacts, mail and calendar one at a time this would help us find the issue
> (I'd bet it's the calendar).
> Anyway, when you click on the account to reauthenticate, does it directly
> show a form with username and password, or does it send you to the Google
> website?
>
> @David: I know this is quite annoying, but do you think you can disable
> the Facebook and the MSN/Live accounts and try again? Since they all
> authenticate at the same time, and using the same method (Oauth), it's
> impossible to follow the logs. :-(
> Also, how often does this happen?
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1052577).
> 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
>

--
    Jack David Baucum
    http://maxolasersquad.com

@Alberto: I have no problem disabling the other services. This is on my laptop, which is mostly a test machine anyways. I get this issue pretty infrequently now so it may be a while until it happens again.

@Alberto: I did a few tests, and it looks like my accounts are going completely crazy. Maybe it's my home folder's fault, with files dating back to the old dapper drake :D
However, the login request appears with at least one between evolution contacts, evolution gmail, evolution calendar, empathy, shotwell enabled. If I enable one of them, the request appears immediately. Obviuosly I always gave access before logging out.
The login request is in the form illustrated by the attached screenshot: a new window appears, and usually I have to enter my credentials in the main window; every now and then the main window appears black, and the form is in the secondary window.
I use the two-step authentication from google, and the first time I added the account it opened a google page in the main window and I had to enter the token from the google auth app.

I am affected too since a few releases (currently using 13.10). I believe it has begun when I enabled two-step verification (2 years ago, maybe? I can't tell).

Developpers: do you have two-step verification activated for your google account?

On 01/29/2014 11:55 AM, Bertrand Mathieu wrote:
> Developpers: do you have two-step verification activated for your google
> account?

I do, but unfortunately it's hard for me to test this as I'm deleting
and recreating my accounts very often.
How often does the issue happen for you?

The proposed package in comment #54 was released in quantal-updates, so removing verify tag.

still persist even in ubuntu 14.04.1 every booting up my laptop this will pop up notification to grant accesss on google.

For people experiencing repeated authentication requests for their google accounts, please note the following.

"Regular" Google accounts should not require you to login everyday. The login authorization generally spans several weeks.

Google Apps for Business accounts, on the contrary, are designed to check for your identity every now and then. If you are requested to authenticate every day when you open your session, that is a requirement set on your account by your provider (Google).

So when reporting issues, please specify whether you are using your personal account, or a business one.

Excellent point. Mine is a regular google account.

Hi,
I have got this issue too with my personal account.

In Ubuntu 14.04 I have seen that in the application "Passwords and Keys" there are 2 entries called "Ubuntu Web Account: id...".
These 2 entries are created in parallel when I create a new account for my Google online account.
One of these entries shows up the
   correct password
with these technical details:
    signon-id: 3, signon-type: 1.

The other entry shows up a string starting with
    "%00%00%00%01..."
and the technical details shows up:
    signon-id: 3, signon-type: 3, signon-method: 1.

Does this help to get a better look into this issue?

Kind regards...

I am a long time Ubuntu user, and I am using Trusty since day one, but I started to experience this just recently, I guess after 14.04.1 was released....

I have a regular Google account, too. Firefox keeps me logged in, Online Accounts doesn't.
I don't have to reboot, on my system the bug is reproducable by rurning off and on the Google account in the Online Accounts diolog.

I started to experience this just recently, I guess also that it was after upgrading to 14.04.1

My account is a regular (=non-business) type of account.

Thanks for the feedback on this issue. I think that it confirms the bug.

We're quite busy with the Phone/RTM release though, so it may take us a few weeks before we get back to that problem with a fix.

This bug is reproducible on mine as wel by either rebooting or by turning my google account off then on again.

Hello>

I started having this problem a few days back and posted a question here.
https://answers.launchpad.net/ubuntu/+question/252680

My Google account is a non-business and everyting has been working fine until now.

I've tried deleting my google account on Ubuntu Online accounts, revoged access to ubuntu and gnove evolution on my google account security settings and adding the account again on ubuntu.
That time it asked me for the google authenticator code, which I entered, but when I logged out and back in... it still was'nt working...

A me too here (having to login after every boot), but I should note that it's happening on both accounts on this computer - my login with my google account and the same with my partners' login and her account. We're both personal Google account users; that it's a system wide issue suggests it's not /home/* configuration file specific.

I think I have found a workaround. With the "Access your Google Calendar" option turned off I don't have to authorize. As soon as I activate that option I have to re-authorize.

I confirm Lenzi's "workaround". I turned off the Google calendar option a couple of days ago and I don't have to re-authorize my Google account anymore.

My Google account is regular (non-business).

This seems to work for me too.

Thanks all for your reports; we'll investigate what's wrong with the Google calendar service; it may be that something has changed in their authentication process, or that we accidentally broke it with some update. I'll keep you posted. :-)

I do not have the "Google Calendar Service" option on the Online Accounts | Google screen.

These are the options available to me.
1. Empathy
2. Evolution Data Server
3. Shotwell
4. Evolution Data Server
5. Photos search plugin
6. Google Drive search plugin

They are all turned "On", but I only use Empathy.

Here for me it's exactly the same as Franco #83 :
"I am using Trusty since day one, but I started to experience this just recently, I guess after 14.04.1 was released… I have a regular Google account, too. Firefox keeps me logged in, Online Accounts doesn't. I don't have to reboot, on my system the bug is reproducible by turning off and on the Google account in the Online Accounts dialog"

Can confirm the workaround seems to work for me too other than the fact that there's no calendar now of course! XD One strange thing I noticed though is in Evolution if you go on a Google account for contacts you get a "This query did not complete successfully. GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._e_2dclient_2derror_2dquark.Code5: Authentication required" error message so I don't know as this is to do with authentication if this is related or not! :S

The workaround does not work for me :

Problem stays, even if calendar service is disabled.

By my side this problem has appeared since I have enabled the "double check process" on Google account - where a code is sent by sms to mobile phone to validate connection. Does it make sense ?

This patch to evolution-data-server might fix the calendar issue:
https://git.gnome.org/browse/evolution-data-server/commit/?h=evolution-data-server-3-12&id=5e9d80092b19f9bd2c02712ab0a50fa70b052c74

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.