GNOME Bugzilla – Bug 728496
GOA configured Google calendar not using OAuth2
Last modified: 2016-04-13 14:04:00 UTC
Hi I'm using fedora 20 (x86_64) with corp gnome 3.12. I recently activated gmail's 2step verification login and I'm getting random gnome-shell modal dialogs to put gmail's password. On evolution I have configured my main gmail calendar via online-accounts but I also have other calendars from gmail using a generated app specific password from gmail. I think this somehow confuses evolution data server because those calendars work (and I can see on gnome-keyring they have the appropiate password) but everytime I add this same password for my main gmail calendar in the shell modal dialog it eventually expires and the modal dialog pop's up again. The calendar still seems to be working fine since if I add new events they appear and everything seems to work, but the random modal dialog in the shell is very annoying. A workaround would be to disable the calendar on online-accounts and add it directly in evolution but I rather try to fix this. Thanks, Here's the packages I think are involved in this bug. Name : gnome-online-accounts Arch : x86_64 Version : 3.12.1 Release : 1.fc20 Name : gnome-shell Arch : x86_64 Version : 3.12.1 Release : 1.fc20 Name : evolution-data-server Arch : x86_64 Version : 3.12.1 Release : 1.fc20
Reassigning to evolution-data-server. There is no code in gnome-online-accounts to show modal shell dialogs like this.
(In reply to comment #0) > Hi > > I'm using fedora 20 (x86_64) with corp gnome 3.12. I recently activated gmail's > 2step verification login and I'm getting random gnome-shell modal dialogs to > put gmail's password. I've been getting this as well since switching to the gnome 3.12 copr and I do NOT use two-factor authentication.
Confirmed in GNOME 3.12.1 under Arch Linux x86_64. The password dialog is shown twice. The first time the password is asked, whatever password is inserted, the dialog reports that a wrong password was provided. During the 2nd request the password is properly accepted.
Sorry, I mean to write confirmed also in GNOME 3.12.2
I confirm this is happening for me also arch 64/gnome 3.12.2
I get this every day for all of my accounts in 3.10 and it's been like that for a long time. Fedora 20, x86_64, did not install anything from copr.
*** Bug 685635 has been marked as a duplicate of this bug. ***
Some relevant comments on this in bug #688351
If the account is using OAuth or OAuth2 for authentication (which can be the case if it originated in GOA), then these dialogs are not just annoying, but also useless. In this case what you want is a machine generated access token and not the user's password.
I can confirm this as well. I am running Gnome 3.12.2 using the COPR by Richard on Fedora 20 x86_64. None of my 3 gmail accounts are using two factor autorization, just plain and simple password login. It appears randomly and I cannot tell what application is showing the dialog. Its a system modal dialog. Asks for password, first time whatever you enter it will tell that its wrong. Second time it accepts the correct password. Bit annoying sometimes.
I may be able to help rule a few things out as triggers: I have 2 computers which both show this bug. My home computer runs Fedora 20 32-bit + Gnome 3.12. It is connected to my personal @gmail.com Google account, which has 2-factor authentication enabled. My work computer runs Fedora 20 64-bit + Gnome 3.12. It is connected to my work Google account, with an email address at my company's domain, which does *not* have 2-factor authentication enabled. I've seen this dialogue appear while I've been watching a video fullscreen in Videos (on my home computer, of course), when there hasn't been any input for at least 30 seconds (so it wasn't triggered by user input). I've found that no matter what password I enter, the dialogue always reports the password as incorrect the 1st time. Then on the 2nd attempt, the dialogue is always dismissed after I enter any password. I deliberately entered incorrect passwords (because it's easier). Eventually (but not immediately) Gnome Shell's calendar stopped showing events from Google Calendar. System Settings's Online Accounts page reported that the account's authentication had expired. After I re-entered the correct password (using the framed log-in web page inside System Settings), Shell's calendar started showing Google Calendar events again. The same thing happened on both computers.
(Inevitably, I forgot to mention:) On both computers, I have uninstalled Evolution.
Debarshi, is this a GOA bug or an e-d-s bug?
(In reply to comment #12) > (Inevitably, I forgot to mention:) > > On both computers, I have uninstalled Evolution. evolution != evolution-data-server
(In reply to comment #13) > Debarshi, is this a GOA bug or an e-d-s bug? EDS. Mostly likely in the calendaring component.
Milan, can you look into this when you get a chance? This issue is very visible for many GNOME 3.12 users. (See also Jakub's comment in bug #688351.)
I'm now experiencing a variant of this bug with GNOME 3.10, except my password is always rejected when typed correctly (whereas for many previous reporters, it is only rejected on the first attempt and then accepted on the second attempt).
CC'ing Milan as per comment 16.
I'm seeing the exact same thing as Michael reports in comment #17... my Fedora 20 machine (standard repos) has just started exhibiting this behaviour in the last few days. It's happening when I unlock the desktop after waking the machine from sleep, so I'd *guess* it's something happening the first time the computer is used during the day.
One correction to my previous comment #19 - it's not just the first time for the day. I *think* it's appearing every time I unlock the screen, so is this maybe triggered either by the session being idle (user away from keyboard, user watching movie, etc) or becoming active again (return to keyboard)?
I have this issue and wanted to provide some additional details based on my experience. - Ubuntu Gnome 14.04 LTS, patched and updated. - 6 different Google accounts - 2 factor authentication on 2 accounts - 5 accounts are Google apps - Set up using Gnome online accounts - Password prompt whenever sync initiated - Password errors as "incorrect" - Repeat attempts to enter password continue to error - Issue appeared for all accounts simultaneously - Removing and re-creating online accounts does not resolve - Evolution still pulls email without error - Calendar sync created in Evolution directly results in --- Same password prompt as on-line accounts: ------ Please enter the password for account "gary@******.net" --- Same incorrect password error as on-line accounts --- Cancel password prompt results in different prompt: ------ Please enter the password for calendar "gary@******.net" (user:gary@******.net, host: www.gooogle.com) --- This prompt accepts password --- Calendar sync then works
I have this occurring *randomly* on gnome-shell-3.13.3-1.fc20.x86_64 It could be something to do with a service syncing automatically, but nothing that I've manually asked to sync. The first time I enter the password, it always says that it's incorrect. It always accepts it in the second try.
Also see general ticket about dialog handling in g-s: bug 688434
As this is Google specific, I guess the reason is Google, thus bug #735311. That is for more recent comments, it wasn't the case in April, where it might be a different issue. There had been planned some changes to not ask for passwords for GOA configured accounts, because it's the GOA responsible to provide the password (or OAuth token), but I not see any similar commit after 3.12.2, thus I cannot tell what the current state of it is (to be precise, I do not recall, I'm sorry).
I removed google from the online accounts and used evolution to set up my google mail and calendar. My google calendar shows up in the top bar and there are no more annoying "enter your password" dialogs.
I can reproduce the issue every time I hit the clock at the top bar, say to know in which day I am living. A good dozen of calendar-password-asking little windows.
(In reply to comment #24) > As this is Google specific, I guess the reason is Google, thus bug #735311. > That is for more recent comments, it wasn't the case in April, where it might > be a different issue. Hey Milan, from the comments in bug #734298, a duplicate of bug #735311, it looks like this original bug indeed persists after bug #735311 has been resolved. Thanks Debarshi for helping us figure this out. What sort of info would help to diagnose the cause of this bug? I'm not running GNOME 3.12 right now, but with 33 people CCed I bet somebody will respond with what you request.
I am not running GNOME 3.12, rpm says gnome-shell-3.10.4-8. But after installing evolution-data-server-3.10.4-5, the dialog box no longer appears at startup.
after removing the gmail account from the online accounts, I used evolution to add the gmail account back and now there are no more dialog boxes and the calendar works/updates fine.
Adding this bug to the target list for GNOME 3.16. See desktop-devel-list for more discussion about this.
*** Bug 741632 has been marked as a duplicate of this bug. ***
*** Bug 709430 has been marked as a duplicate of this bug. ***
I still lack of a reproducer for this state. It might be something with GOA password provider, on the first look (according to comment #29), but maybe something completely different. In any case, I made some extensive changes for 3.13.90 which may eventually change some things here as well. More info at [1]. Can anybody give it a try, please? The 3.13.90 is a development version, which will be released on February 16th, but trying with evolution 3.14.x will be fine as well. https://mail.gnome.org/archives/evolution-hackers/2015-February/msg00000.html
*** Bug 743732 has been marked as a duplicate of this bug. ***
Request still standing to anybody running into this: (In reply to Milan Crha from comment #33) > Can anybody give it a try, please? The 3.13.90 is a development version, > which will be released on February 16th, but trying with evolution 3.14.x > will be fine as well. > > https://mail.gnome.org/archives/evolution-hackers/2015-February/msg00000.html
I'm running into this on 3.14.1, debian unstable. It appears to be google calendar, other bugs with similar symptoms have been filed and fixed by 3.12 but the problem persists.
(In reply to Andrew from comment #36) > I'm running into this on 3.14.1, debian unstable. Thanks for the update. The 3.14.1 is a GNOME version. Evolution currently skips 3.14 series completely and will merge with GNOME version again (the decision was made the last week), thus the Evolution version with the changes mentioned at comment #33 will be Evolution 3.16.0. > It appears to be google calendar, other bugs with similar symptoms have been > filed and fixed by 3.12 but the problem persists. What is the exact evolution(-data-server) version, please? Is the Google calendar configured through GNOME Online Accounts? The part I miss on this bug report is a reproducer. There might happen something odd within the libraries, but I still do not know what. It sometimes happens to me that libsecret gets crazy after I restart evolution processes and the libsecret reports no passwords or some such issue. A repeated restart of the evolution processes usually helps to cure the problem.
debian package version is 3.12.9~git20141128.5242b0-2+deb8u1 the account is configured through GOA
(In reply to Milan Crha from comment #37) > > It appears to be google calendar, other bugs with similar symptoms have been > > filed and fixed by 3.12 but the problem persists. > > What is the exact evolution(-data-server) version, please? Is the Google > calendar configured through GNOME Online Accounts? evolution 3.12.9 eds 3.12.9 Google calendar configured through GOA > The part I miss on this bug report is a reproducer. There might happen > something odd within the libraries, but I still do not know what. It > sometimes happens to me that libsecret gets crazy after I restart evolution > processes and the libsecret reports no passwords or some such issue. A > repeated restart of the evolution processes usually helps to cure the > problem. It does happen without any user interaction. From what I saw on SLED12 logs (where we ship evolution/e-d-s 3.10.4 with the latest google calendar fix from 3.12), it seems related to the oauth2 token which expires and causes a keyring popup query. But if you cancel this query, a new token is properly fetched anyway and future updates in calendar are properly retrieved.
moving off tracker.
*** Bug 727247 has been marked as a duplicate of this bug. ***
I think I finally managed to reproduce the problem here, and eventually did figure out the problem. I have configured a GMail account in GOA and when I restart all background processes the GOA Calendar could fail with "Authentication required" error. It didn't do that always, which made it even more confusing. I tried to reproduce it with debugging on, and with some other debugging being added, and it turned out that in time the calendar was opening it used an ESource which had set plain/password authentication method for this GOA calendar, but that is wrong, because GOA-configured Google calendars use OAuth2 token provided by GOA. The interesting thing was that the authentication method was made plain/password only for a short time, then it was switched to OAuth2, but the evolution-calendar-factory had still the "old" method set. The Google server returned an error 403 Forbidden, with a description like this "Too many unauthenticated attempts were done today" (I do not have exact message copied, unfortunately). That couldn't be worked around by providing the password, because the CalDAV calendar didn't send it to the server in the first place. Matthew fixed this for the bearer authenticator within bug #735311. Further eds code investigation led me to a very simple fix, to avoid the switch between the authentication methods entirely, by using up-to-date values when (re-)populating it. Created commit 3a01f63 in eds master (3.17.2+) Created commit 8cdd88a in eds gnome-3-16 (3.16.3+)
Will this be backported to the versions used in Fedora 21? (I get lost with the Evo version numbers).
(In reply to Bastien Nocera from comment #43) > Will this be backported to the versions used in Fedora 21? I didn't do it, but I surely can. The evolution-data-server-3.12.11-3 is currently building at [1]. I'll create an update once it's done. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=9751574
(In reply to Milan Crha from comment #44) > (In reply to Bastien Nocera from comment #43) > > Will this be backported to the versions used in Fedora 21? > > I didn't do it, but I surely can. The evolution-data-server-3.12.11-3 is > currently building at [1]. I'll create an update once it's done. > > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=9751574 I meant in the upstream version of evolution-data-server used in Fedora 21, so, yes, the gnome-3-12 branch in this case.
(In reply to Bastien Nocera from comment #45) > I meant in the upstream version of evolution-data-server used in Fedora 21, > so, yes, the gnome-3-12 branch in this case. Aha, in that case no, gnome-3-12 branch is dead for the evolution products.
(In reply to Milan Crha from comment #46) > (In reply to Bastien Nocera from comment #45) > > I meant in the upstream version of evolution-data-server used in Fedora 21, > > so, yes, the gnome-3-12 branch in this case. > > Aha, in that case no, gnome-3-12 branch is dead for the evolution products. Yet, it's still used in a number of products you maintain. Wouldn't it be easier to backport the fixes you make in your products to gnome-3-12 as well, so that other distributors can use them?
*** Bug 738628 has been marked as a duplicate of this bug. ***
There still was a possibility to face this issue. I addressed it with the below change. Created commit 4b14c7e in eds master (3.21.1+) Created commit 140f9ca in eds gnome-3-20 (3.20.2+)