Google talk "Requires Authorization" after suspend/resume

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

Same problem here, rebooting doesn't even help most of the time. Removing the google account and adding it again makes it work until the next reboot or suspend.

Guys make some thing we have to go to pidgin)

Same problem for me.
Can Seahorse app be in conflict with Google Online Account ?

I have the same problem on Ubuntu 13.04. I have 2 Google accounts configured.

I have two Google accounts as well, could that be a relevant factor?

@jeroen, I have the problem with just one google account

I only have the one GTalk account in Empathy (I'm using Pidgin for my own accounts, was using Empathy for a work-specific account), and encountered the bug as well. Did not even have empathy running befroe, this bug came up as soon as I started the application (and have not run the application since 2-3 reboots ago)

Ubuntu 12.10/Mint 14, Empathy v3.6.0.3

The following event shows up in syslog:

signond[6900]: ../../../../src/signond/signondaemon.cpp 360 init Failed to SUID root. Secure storage will not be available.

The empathy debug log shows ("empathy-debugger"):

gabbleconnection-DEBUG: 20/05/13 10:47:25.225645: gabble_connection_constructed (connection.c:547): defaulted resource to fa965dbf
wocky/-DEBUG: 20/05/13 10:47:25.343826: wocky_xmpp_writer_stream_open: wocky-xmpp-writer.c:302: Writing stream opening: <?xml version='1.0' encoding='UTF-8'?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to="gmail.com" version="1.0">
wocky/-DEBUG: 20/05/13 10:47:25.375200: handle_stream_open: wocky-xmpp-reader.c:435: Received stream opening: stream, prefix: stream, uri: http://etherx.jabber.org/streams
wocky/-DEBUG: 20/05/13 10:47:25.375298: handle_stream_open: wocky-xmpp-reader.c:454: Stream opening attribute: from = 'gmail.com' (prefix: <no prefix>, uri: <no uri>)
wocky/-DEBUG: 20/05/13 10:47:25.375334: handle_stream_open: wocky-xmpp-reader.c:454: Stream opening attribute: id = 'BE127A149FA0DD9F' (prefix: <no prefix>, uri: <no uri>)
wocky/-DEBUG: 20/05/13 10:47:25.375366: handle_stream_open: wocky-xmpp-reader.c:454: Stream opening attribute: version = '1.0' (prefix: <no prefix>, uri: <no uri>)
wocky/-DEBUG: 20/05/13 10:47:25.375550: _end_element_ns: Received stanza
* features xmlns='http://etherx.jabber.org/streams'
    * starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'
        * required
    * mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
        * mechanism
            "X-OAUTH2"
        * mechanism
            "X-GOOGLE-TOKEN"
wocky/-DEBUG: 20/05/13 10:47:25.375628: _write_node_tree: Serializing tree:
* starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'
wocky/-DEBUG: 20/05/13 10:47:25.401357: _end_element_ns: Received stanza
* proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'
gabbletls-DEBUG: 20/05/13 10:47:25.694149: gabble_server_tls_manager_verify_async (server-tls-manager.c:340): verify_async() called on the GabbleServerTLSManager.
gabbletls-DEBUG: 20/05/13 10:47:25.694252: gabble_server_tls_manager_verify_async (server-tls-manager.c:362): ignore-ssl-errors is set, fallback to non-interactive verification.
wocky/-DEBUG: 20/05/13 10:47:25.725522: wocky_xmpp_writer_stream_open: wocky-xmpp-writer.c:302: Writing stream opening: <?xml version='1.0' encoding='UTF-8'?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to="gmail.com" version="1.0">
wocky/-DEBUG: 20/05/13 10:47:25.805485: handle_stream_open: wocky-xmpp-reader.c:435: Received stream opening: stream, prefix: stream, uri: http://etherx.jabber.org/streams
wocky/-DEBUG: 20/05/13 10:47:25.805557: handle_stream_open: wocky-xmpp-reader.c:454: Stream opening attribute: from = 'gmail.com' (prefix: <no prefix>, uri: <no uri>)
wocky/-DEBUG: 20/05/13 10:47:25.805599: handle_stream_open: wocky-xmpp-reader.c:454: Stream opening attribute: id = '22DE5ED1D43B1939' (prefix: <no prefix>, uri: <no uri>)
wocky/-DEBUG: 20/05/13 10:47:25.805633: handle_stream_open: wocky-xmpp-reader.c:454: Stream opening attribute: version = '1.0' (prefix: <no prefix>, uri: <no uri>)
wocky/-DEBUG: 20/05/13 10:47:25.805804: _end_element_ns: Received stanza
* features xmlns='http://etherx.jabber.org/streams'
    * mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sas...

I discovered that deleting the Jabber GTalk account and replacing it with a full Google account solves the problem, so it looks like a bad interaction with the gabble ---> signond --> google-talkplugin combination.

@TJ, I have this problem and I've always used the full UOA google account setup (and ever since ubuntu 12.10 I think thats the only way you can setup a google account in empathy, because afiak they have totally tore out the legacy empathy accounts diaglogue and replaced it with UOA)

I experience the same bug. If I want empathy to connect to my google talk account I must delete it from my account list and suppress the authorization for ubuntu in my google account settings then I have to add again my google account in ubuntu.

One thing strange is that when I add again my google account, chromium (which is not my default browser) is launched to a blank page (about:blank) twice: for the login page and for the authorization page. This does not stop the authorization process.

I am runnig a 13.04 ubuntu version uptodate.

Confirming on 13.04, empathy 3.6.4-0ubuntu4.1, 64bit.

I have dual-account scheme: 1st: google apps mail account, 2nd: gmail.com account
After suspend & resume, the google apps account logs in, while gmail.com does not.

Security history on the gmail account (https://security.google.com/settings/u/1/security/activity) does not show login from the account.

This bug is quite similar to https://bugs.launchpad.net/ubuntu/+source/telepathy-gabble/+bug/1170832

I have a similar problem since I had updated from 12.04 to 13.04. Now I use 13.10 with saucy-proposed PPA (to have Facebook work in Empathy). I have two Google accounts, which can unpredictibly not connect at Ubuntu start (most of the time at least one of them can't connect, I delete the account and create it again for it to connect).

Also affects trusty after updating from saucy.

I confirm it has not been fixed on 14.04.

I confirm too that this bug has not been fixed on 14.04.

I can confirm this bug on 14.04, and that a reboot indeed fixes the problem. How does this bug not get more priority, it makes empathy pretty unusable?

I also confirm this still happens in ubuntu 14.04, removing the account and adding it again solves de problem, but after reboot it happens again.

Same bug on ubuntu 14.04

Restarting after installing last kernel updates (3.13.0-29-generic) seems to have solved the problem, because my google apps account signed in without having to delete and recreate it.

Still not working for me with kernel 3.13.0.29 on 14.04

Correction, the second time I reboot with the kernel 3.13.0-29-generic and next ones, the error continues to happen. I've again to delete my google apps account and recreate it to get it working on empathy.

Yes same bug. with Ubuntu 14.04
Tested with
1. 13.03.0-29-generic
2. 3.15.0-031500-generic #201406081435

This is probably the same bug as https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1069531 in which case doing:
killall -6 signonpluginprocess
May allow google to log in.

This problem persists in 14.04 for me as well. One of the two Google accounts I add will fail even during the same session with the "authorisation required" error.

I have stopped using Empathy and the Online Accounts configurator completely due to this bug, although I give it a go whenever I move to a newer version of Ubuntu to see if the bug persists. Oddly enough, other messaging applications seem fine with my Google accounts, and no authorisation of any kind is needed beyond my credentials.

Thanks for the tip, Phasmus. Killing the process on 14.04 seems to help my issue as well. Otherwise Empathy is downright unusable given its wildly inconsistent behavior.

Is this maybe related to two-factor authorization? I have the same problem (two Google accounts) but I also use 2-factor auth.

It's been two years now this extremely annoying bug exists… and its importance is still "undecided".
On the other hand, Pidgin works like a charm.