On 10/28/2015 05:48 PM, Niklas Wenzel wrote: > The rationale here was to somehow show the user in a more permanent way > that the token has expired. If we don't want to revoke access to > account-polld, there needs to be another way of indicating this on the > accounts overview page. > Furthermore, revoking access would save us from implementing logic in > account-polld to stop polling accounts with expired tokens if we cannot > recover from the issue. (libsignon-glib can indicate what exactly was > the reason, so we could find some, e.g. "invalid credentials", that we > mark as non-recoverable.)
Well, yes, there are some non-recoverable errors, but they shouldn't normally happen: they can happen only if there is a filesystem corruption or if the user manually modified the accounts or credential database, or because of some bugs. If such a situation happens, we could show a message to the user asking him to delete and re-create the account. > The account is not broken :-) > > Can't we consider it to be broken if libsignon-glib yields an "invalid > credentials" error? Yes, but... > The fact that account-polld encounters this error means that any other > app *using the same application key* as account-polld will meet the same > error. I would argue that no other app should use the same key, so the > problem lies almost entirely on the app which encounters the error. > > I would argue that this does not hold if we are talking about the > afore-mentioned "invalid credentials" error. ;) ...I (wrongly) assumed we were talking about authentication errors due to expired tokens. :-) The reason is that I never met such "invalid credentials" errors; if you happen to meet them, please file bugs, they definitely need to be addressed with the highest priority. > In order to solve the authentication issue with account-polld we need to > find a UI process which can repeat the authentication with the same > account, using the application key from account-polld. This could be > Dekko, or indeed it could be some component in Online Accounts itself. > > Personally, I wouldn't want to put this code into Dekko. What if the > user never opens Dekko or even uninstalls it? Yes, it makes sense that this code is in Online Accounts; however, there will always be a mail client installed (if not, it's fine that account-polld ignores the account), and this application could be the "host" of the re-authentication process -- it doesn't need to perform it itself, but it could trigger it. It might even be possible to have it totally implicit: the system detects that the mail client has started, and automatically performs the re-authentication of the mail accounts, on top of the mail client UI, which doesn't know anything about it. :-) Ciao, Alberto -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
