Summary: | Google account fails to authorize after reboot | ||
---|---|---|---|
Product: | [Unmaintained] telepathy | Reporter: | Thomas Pfeiffer <thomas.pfeiffer> |
Component: | general | Assignee: | Telepathy Bugs <kde-telepathy-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | mklapetek |
Priority: | NOR | ||
Version: | 15.04.0 | ||
Target Milestone: | Future | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Thomas Pfeiffer
2015-05-12 19:05:25 UTC
Thanks for the report. Do you perhaps have any remaining bits of kde-telepathy 0.9? The Google auth uses oauth, it shouldn't require any passwords at all. Whatever caused this, it seems fixed with 15.04.1 (without me changing anything). Scrap that, it just appeared again for whatever reason :( The message was "There was a problem while trying to connect [my gmail address which I remove here for privacy reasons] - Authentication of your account failed (is your password correct?)" Is there any way how I can diagnose whether this is caused by some leftover from 0.9? This pretty much breaks Ktp for me and I'm probably not the only person upgrading from 0.9 Hmm, I'm not sure. This would mean the password is cleared after reboot, which doesn't make much sense. I guess you're using normal distro packages? Can you check all of ktp packages are from 15.04.x, mainly ktp-accounts-kcm and ktp-auth-handler? Everything is on 15.04.1, except for call-ui which says 0.9.0 Ah, actually, do you have signon-kwallet-extension package? Or any package that has signon and kwallet in the name? ;) The passwords are stored into kwallet under "accounts", can you check that after a reboot you have a correct password in kwallet? Also, for the record, I'll be merging (probably today) a new solution into master which will make all this pain go away. I'll see if there's a way to get it into stable as well. (In reply to Martin Klapetek from comment #7) > Ah, actually, do you have signon-kwallet-extension package? Or any package > that has signon and kwallet in the name? ;) I do have signon-kwallet-extension 15.04.1-1 > The passwords are stored into kwallet under "accounts", can you check that > after a reboot you have a correct password in kwallet? Is the kwallet5 wallet the same as the kwallet4 wallet? The one I can open with KWalletManager does not have an "Accounts" category. Ah yes, the KWalletManager5 was not yet released, so you can look only into KWallet4 while the secrets are stored in KWallet5. I'm unsure what else to advise other than waiting a bit for the new version. Sorry... The problem still persists even with 15.08 :( Can you please try removing everything in ~/.config/libaccounts-glib and ~/.config/signond and ~/.local/share/telepathy/mission-control/accounts.cfg, then kill mission-control-5, then try adding the new account again? This is really strange issue, it almost looks like the credentials are not being stored on disk and I've no idea why would that be. Alternatively, if you haven't done the above, can you please run "ktp-auth-handler --persist" (in libexec) after reboot and try connecting, then post the output here (check for sensitive data). I have removed all the things you mentioned and re-added the account, but the problem remains. Actually it's even stranger: Rarely, it does authenticate again after a reboot, so it seems liek the credentials do get saved but the authentication fails most of the time anyway. Running ktp-auth-handler --persist gives me telepathy-qt: "tp-qt:0.9.6.1()" Unable to register client: busName "org.freedesktop.Telepathy.Client.KTp.ConfAuthObserver" already registered telepathy-qt: "tp-qt:0.9.6.1()" Unable to register client: busName "org.freedesktop.Telepathy.Client.KTp.SASLHandler" already registered telepathy-qt: "tp-qt:0.9.6.1()" Unable to register client: busName "org.freedesktop.Telepathy.Client.KTp.TLSHandler" already registered No handlers registered. Exiting How can I execute it before they are registered? That means it is already running, so just kill it first. Thomas, did comment #15 help resolving the issue? Please add a comment. Sorry for not commenting earlier. I didn't execute comment #15 but the problem now doesn't seem to appear anymore now, maybe after some package upgrade. I'll just mark the bug as fixed and would reopen it in case if happens again. |