© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
When an app wants to use an account, it first needs to be authorized by the user. This is an offline operation, which happens locally on the user's device. It's handled by dialogs in the second column of
https:/
(note that the dialog at the bottom, is the dialog that handles the account creation, essentially the same that the user would see if he created the account from System Settings -> Online Accounts: the only difference is that once the account creation completes successfully, the application is added to the whitelist of apps which can use the account -- again, it's just a local operation)
As soon as the application is granted the permission to use an account, typically it will try to get its password or authentication token; when dealing with OAuth, most of the times the very first time that this happens the remote server will run its own checks and require us to show a webview to the user, asking an additional confirmation (after which, the server remembers that this app has been authorized to use the account, and will return us an access token, which is specific to that app.
Now, access tokens do expire. It can be a matter of hours, but most typically it's months or even years. When that happens, we need to show the remote server's contents in a webview and the user will have to renew the authorization.
The dialogs you added on the right column cover exactly this case: it's when an app which is *already locally authorised* to use an account finds out that the access token is no longer valid (or password, if the user has changed it on the remote server -- think of UbuntuOne, which is not OAuth based).
I think that your design covers the needed cases, but I belive that the "Allow" and "Do not allow" buttons you have on the third column are misnamed: I would rename "Allow" to something like "Renew authentication". As for the "do not allow", I would either remove it completely or (better) rename it do "revoke authorization": it's effectly about *locally* toggle the "enabled" flag for the requesting application, so that it will stop ever trying using this account (and if the user opens the account in the System Settings, he'll see that the app is now disabled).