© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
Just to complement the bug report with more information which might be useful for designers (and for myself, when I get back to this):
* WHEN
The need for a user interaction might arise at any time, depending on the remote service's policy. It will typically happen when an access token expires, or when an application requests new permissions or changes its key.
*WHAT
The user interaction could potentially be anything which can be embedded in a website, but typically it will be a login form or a page where the user has to confirm that he authorizes the application to get certain permissions on his account; or even a combination of the two. In any case, this is directly coming from the service provider, and we have no control over it (it's something which we embed in a web view element).
* OUR DATA
What we know about this request is:
- the affected account (which we could show the provider name, the user ID, an icon, etc.)
- the requesting application, *if it is part of a click package*; unfortunately, if the requesting process is a system service (or an application installed as a .deb package), establishing the source of the request will be more difficult.
Initially the plan was to use snap decisions for this, and this is probably the easiest short-term solution for the implementation side:
https:/
However, this was never designed in detail, and better solutions might be possible.