Provide a way to update existing accounts' authentication parameters

Bug #1047191 reported by Alberto Mardegan on 2012-09-07
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Online Accounts: GNOME Control Center
Critical
Alberto Mardegan

Bug Description

Sometimes it happens that the authentication parameters change. Some of the possible reasons are:

a) the provider itself changes the authentication method on the server side
b) we want to change some authentication parameters in order to improve the user experience (for example, request the mobile version of the website, or do some tricks to get a longer-lived access token)
c) we need to request additional permissions for some new application
d) new application key

With the possible exception of the last point, in all the other cases we definitely want to update the parameters on the user's existing accounts (upgrading the application keys might not be desirable, if the existing ones work and there is some user quota restriction on all the application keys emitted for this provider).
At the moment, this does not happen: if the authentication parameters stored inside the account are no longer working, currently the user needs to delete the account and recreate it.

To solve this problem, we need to find a way to update the existing accounts' authentication settings -- and figure out when this is actually needed.

PROPOSED SOLUTION
=================

The updating logic should belong to the account plugin; the main question is how and when to trigger the update.
When invoked by the GNOME control center applet, the account plugin could check the settings on the account and update them as needed.
  Pros:
  - the account plugin could do this before starting the reauthentication, when accounts need to be re-authenticated.
  Cons:
  - would not automatically cover case (c): the new applications get a valid access token anyway, but it has insufficient grants. So, the account is not set to need-attention state, and the user might not visit the control center.

Case (c) could probably be handled by the application itself: it could explicitly specify the OAuth scopes it needs before starting the authentication, if they are a superset of those requested by the account (this can be done, for instance, by writing the scopes into the libaccounts's .service file).

Related branches

Alberto Mardegan (mardy) on 2012-09-07
affects: online-accounts-gnome-control-center → online-accounts-account-plugins
Alberto Mardegan (mardy) on 2012-09-09
Changed in online-accounts-account-plugins:
importance: Undecided → Critical
Alberto Mardegan (mardy) on 2012-09-10
Changed in online-accounts-account-plugins:
assignee: nobody → Alberto Mardegan (mardy)
status: New → In Progress
affects: online-accounts-account-plugins → online-accounts-gnome-control-center
Alberto Mardegan (mardy) on 2012-09-10
Changed in online-accounts-gnome-control-center:
status: In Progress → Fix Committed
David King (amigadave) on 2012-09-18
Changed in online-accounts-gnome-control-center:
milestone: none → 0.0.15
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers