← Back to team overview

ubuntu-phone team mailing list archive

Re: Disable accounts with invalid credentials

 

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


References