← Back to team overview

ubuntu-phone team mailing list archive

Re: Disable accounts with invalid credentials

 

Hi all,

Sorry for the late reply. Real life has kept me busy. ;)

@Alberto: Thank you for filing the bug report. :)

I don't think that we should revoke the access to account-polld: that's
> a setting that's been decided by the user, and if we revoke it then we
> should also teach the user how to set it back. It's not trivial, and I
> think there are simpler solutions to this.


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.)

I want to argue that this logic be placed elsewhere. If/when account-polld
> becomes unnecessary, we lose this logic. So any code we add to
> account-polld that we want for all time, essentially becomes technical debt.
>
> And if a Google account is broken, who is going to tell the user if
> account-polld does not “see” it? If account-polld is the canary in the
> accounts mine, then a broken Google account only accessed by calendard and
> contacts, will stay silently broken.
>

+1

The account is not broken :-)


Can't we consider it to be broken if libsignon-glib yields an "invalid
credentials" error?

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. ;)

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?

I believe that we could have something similar on the phone, but since
> the amount of work (and risk) is quite considerable, I'd rather wait to
> see the UX designers' plan on how this should work UX-wise, and then
> come up with a technical solution which implements that.


Sounds sane. :)

Cheers,
Niklas

2015-10-19 13:20 GMT+02:00 Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>
:

> On 19.10.2015 12:53, Andrea Bernabei wrote:
> > Is there a bug already to track that? Does UX know that you're waiting
> > for such a solution?
> > If either of the answer is false, we have to fix that first :)
>
> I was relying on IRC, but your suggestion is indeed most reasonable:
>
> https://bugs.launchpad.net/ubuntu-ux/+bug/1507540
>
> Ciao,
>   Alberto
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>

Follow ups

References