GNOME Bugzilla – Bug 755236
Gmail mailbox remains hidden after authentication fails with correct password
Last modified: 2018-05-22 07:42:54 UTC
I triggered a security alert @google and the login failed for reasons unrelated to the password. Password is correct, login failed for other reasons. At this point: - the mailbox isn't available on the sidebar and no operation on it is being done - Geary seems to try a login only if I input a password that isn't the one that's saved. - If I input the right password, nothing happens and the mailbox remains hidden. - Geary doesn't allow me to save the account with an empty password at this point. - Save password doesn't behave correctly at this point, if unchecked Geary still picks up the saved password. I couldn't find a way from within the app to reactivate the mailbox
Mass-reassigning bugs that won't make 0.12.
IIUC the report, I had a similar issue recently. Gmail was already added to Geary and was working correctly. Then "sometimes" it prompted me for entering the password again and it never worked, as if the password was not correct. After some tries I realized that the issue was triggered only when I was connected to the Internet using my Android phone as hotspot. I guess that Google recognized the different IP or the Android device and used some more strict security checks. In fact I received an SMS on my phone saying: Your password for account@gmail.com has just been used by another user. See: google.com/blocked I went there and unblocked that device. Then I never had that problem again. I guess that fixing Bug #746705 (Support OAuth2) would solve these issues? @Giacomo, do you remember how did you trigger that security alert? Can you still reproduce this error?
I think this issue is directly related to the way Geary authenticates to GMail, as this issue also occurs when setting up a Google account. I tried to add my Google account and Geary told me that my username/password was incorrect. Actually, it's just that Google blocks authentication attempts because of a security feature they enforce to "secure our account". The solution is to "use stronger security measures" in Geary - implementing OAuth 2.0 - as @Federico said. You can see their statement here : https://support.google.com/accounts/answer/6010255?hl=en As a workaround for this bug, you can allow less secure apps to access your Google account here : https://myaccount.google.com/lesssecureapps
This was partially fixed by Bug 713006, although some more UX polish is needed there. At least now with current master the account will be displayed and remain visible when an auth error occurs. I have a feeling that the "reasons unrelated to the password" was probably Google wanting a captcha filled out to proceed, i.e. Bug 713744. While supporting OAuth might make that happen less often, we should at least still handle this situation gracefully as well. As such, I'll close this as a duplicate of Bug 713744, but please feel free to re-open if this diagnosis is incorrect. *** This bug has been marked as a duplicate of bug 713744 ***
Though it might be a duplicate, allowing less secure apps to connect to our Google account is a deprecated/not recommended feature. And I'm not sure that this is a duplicate. As I said, it is now (at least for me) impossible to connect to a Google account if you haven't "allowed less secure apps" in your Google account settings. Doing so is not a good idea, I think it's on Geary's side to match Google stricter connection rules, that is OAuth 2.0 ?
Rémi, enabling "less secure apps" is perfectly secure. That phrase is a marketing ploy by Google to get GMail users to exert pressure on email application developers so they feel obliged to add support Google's proprietary, non-standard OAuth extension for IMAP. However, the original report above from Giacomo above and as confirmed by Federico suggests that logging in to GMail was working fine for them until a Google security alert occurred and then it stopped working. This should have been reported by Geary somehow so they knew what was happening. That's why this particular bug is a duplicate of Bug 713744. Adding support for Google's OAuth extension is a separate issue, which covered by Bug 746705.