I would identify two different (but related) issues here: 1. Interactive auth dialog can pop endlessly if user doesn't react on them. i.e. when first dialog opens and user doesn't not provide auth token and doesn't cancel/close it in time, then in some time (polling interval) second dialog pops, and so on. 2. Interactive auth dialog initiated after any network error which can occur when trying to refresh auth token. Consider the case: 1) I got auth token from google 2) provided it to GData plugin. Now it is able to work fine. 3) in ~1 hour I faced with network issue. -- at this point GData tries to refresh token and it is not able to do this due to network issue. As result I again got interactive auth dialog (however my token is valid). I think this is really annoying for user and asks for actually unnecessary actions (there is really no reason for token regeneration). I would propose to initiate auth dialog only in case when GData explicitly got FORBIDDEN response from google, in other cases (usually just network issues) ignore the error and retry token refresh again until succeeded. I'm attaching patch which solves these two issues for me. I'm not sure that it is done in a good way, but it could be as a starting point.
Created attachment 1706 [details] interactive auth dialog patch
Is anyone maintaining the gdata plugin? This bug is a year and a half old without any but the original comment. I would like to add a vote to bump this up. What's wrong with Viacheslav's patch? Can it be incorporated soon please?
(In reply to comment #2) > Is anyone maintaining the gdata plugin? This bug is a year and a half old > without any but the original comment. I would like to add a vote to bump > this up. What's wrong with Viacheslav's patch? Can it be incorporated soon > please? What versions of libgdata and claws-mail are you using?
(In reply to comment #3) > What versions of libgdata and claws-mail are you using? Claws Mail version 3.15.1-dirty /usr/lib64/libgdata.so.22.2.1 Thanks for your attention.
(In reply to comment #4) > /usr/lib64/libgdata.so.22.2.1 This is not the version of libgdata. I was asking whether you had version 0.17.2 or greater.
Duh, sorry. libgdata-0.17.8-1.fc26.x86_64
Frankly, loading the plugin and then not logging in is not the most interesting use case, so I forgot about it. Concerning networking issues, those are better dealt with on a higher level, and I didn't feel comfortable with restricting the auth dialog so much, so I didn't apply the patch yet. I think only truly sporadic issues (like the mentioned networking issues) should be ignored (and reported in the log), otherwise there is a bigger chance of being locked out without realizing. But I agree that networking issues and the like could be handled more robustly. I'll see when I can have a look.
"loading the plugin and then not logging in" is not the use case in question. Viacheslav describes my problem correctly in his second bullet. Rephrasing the problem: I'm logged in with the GData plugin having a authorized token and everything is working fine. Then sometime later and unrelated to anything here, my router requires rebooting. If the GData plugin doesn't notice that I rebooted my router, it continues to work fine. If the GData plugin does notice, it asks for a new token when it didn't need one. My reading of the Google API, which could be mistaken, says that I should only have to authorize my email app once per lifetime, not once per week. At the risk of speaking for Viacheslav, I believe the problem in his first bullet would disappear, or at least be much reduced if the problem in his second bullet were fixed.
(In reply to comment #8) > "loading the plugin and then not logging in" is not the use case in > question. It's exactly the use case of the first bullet point. In fact, I can't reproduce it.. I get at most two dialogs (one at startup, another one for the first periodic check). But that can be fixed. As for the second bullet point, I am not a fan of silently ignoring all kinds of errors, but I agree that sporadic network issues shouldn't trigger an interactive authorization request, but could be just logged.
Changes related to this bug have been committed. Please check latest Git and update the bug accordingly. You can also get the patch from: http://git.claws-mail.org/ ++ ChangeLog 2018-06-25 23:28:14.747865449 +0200 http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=a5b04a37b808eaa05ea13ae036a73da160dfb4ab Merge: ec10edc 70d4cce Author: Colin Leroy <colin@colino.net> Date: Mon Jun 25 23:28:09 2018 +0200 Merge branch 'master' of file:///home/git/claws http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=70d4cce5c4200119be1a50ce23b1c227c0056f67 Author: Holger Berndt <hb@claws-mail.org> Date: Mon Jun 25 23:22:26 2018 +0200 GData plugin: Request interactive auth only in case of auth issues At the same time, make (now potentially ignored) errors more visible in the status bar in the same way as background mail fetching errors are reported. Fixes bug #3754 Modified version of the patch by Viacheslav Gagara on that bug report. http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=a6913537c97260ec3e51914e66f4443b61fe81a0 Author: Holger Berndt <hb@claws-mail.org> Date: Sun Jun 24 16:16:46 2018 +0200 GData plugin: Only allow one interactive auth session at a time