Handle server-side token invalidation in a user-friendly way
Bug #1347771 reported by
Martin Albisetti
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Online Accounts setup for Ubuntu Touch |
Fix Released
|
High
|
Alberto Mardegan | ||
| ubuntuone-credentials |
New
|
Undecided
|
Unassigned | ||
Bug Description
When a user changes their password in Ubuntu SSO (or usually in other services), the current tokens are no longer valid.
Online Accounts needs to detect this situation and ask the user to log back in as soon as it's being used, and transparently ask the user for their user/password, explain that the session had expired and happily let them go on with what they were doing.
Related branches
lp:~mardy/ubuntu-system-settings-online-accounts/qml-dialog
- David Barth (community): Approve
-
Diff: 588 lines (+492/-2)7 files modifieddebian/control (+1/-0)
online-accounts-ui/dialog-request.cpp (+286/-0)
online-accounts-ui/dialog-request.h (+54/-0)
online-accounts-ui/online-accounts-ui.pro (+3/-0)
online-accounts-ui/qml/SignOnUiDialog.qml (+115/-0)
online-accounts-ui/signonui-request.cpp (+32/-2)
online-accounts-ui/ui.qrc (+1/-0)
| Changed in ubuntu-system-settings-online-accounts: | |
| importance: | Undecided → Medium |
| status: | New → Triaged |
Revision history for this message
| Alberto Mardegan (mardy) wrote | #1 |
| Changed in ubuntu-system-settings-online-accounts: | |
| importance: | Medium → High |
| assignee: | nobody → Alberto Mardegan (mardy) |
| Changed in ubuntu-system-settings-online-accounts: | |
| status: | Triaged → Fix Released |
To post a comment you must log in.
I need to investigate this a bit, just to make sure that everything is fine on our side, but here is how the flow should go, supposing that the password has been changed remotely:
1) the app (for instance the U1 store app) asks OA to authenticate against U1
2) OA (signond) defers the job to the U1 authentication plugin
Now, if the U1 plugin can detect that the password is no longer valid:
3) The U1 plugin emits a userActionRequi
4) OA gets the new password from the user, and returns it to the U1 plugin
5) the U1 plugin responds with the new authentication tokens
If the U1 plugin cannot detect that the password:
3) The U1 plugin returns an invalid token to the app
4) When the app tries to use some U1 APIs, it gets an error which clearly indicates that the token is invalid
5) The app tells to the U1 plugin (via OA) that the token is invalid. This can be done by adding a specific mechanism to the plugin, or by passing some parameter to the session data.
6) The U1 plugin emits a userActionRequi
7) OA gets the new password from the user, and returns it to the U1 plugin
8) the U1 plugin responds with the new authentication tokens