account-plugins (0.13+16.04.20160405-0ubuntu1) xenial; urgency=medium
[ Alberto Mardegan ]
* After the authentication, retrieve the username in Google, Facebook,
Flickr and Twitter plugins (LP: #1565772)
* debian/control, debian/libaccount-plugin-facebook.install,
debian/libaccount-plugin-flickr.install,
debian/libaccount-plugin-twitter.install:
add packages containing plugin modules.
* debian/account-plugin-facebook.install,
debian/account-plugin-flickr.install,
debian/account-plugin-twitter.install:
remove unneeded webkit-options files.
[ CI Train Bot ]
* No-change rebuild.
-- David Barth <david.ba...@canonical.com> Tue, 05 Apr 2016 12:57:47
+0000
** Changed in: account-plugins (Ubuntu)
Status: In Progress => Fix Released
** Changed in: account-plugins (Ubuntu Xenial)
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnome-control-center-
signon in Ubuntu.
https://bugs.launchpad.net/bugs/1565772
Title:
Allow plugins to decide which username to set on new accounts
Status in Online Accounts: Account plugins:
Fix Released
Status in Canonical System Image:
Fix Committed
Status in Online Accounts: GNOME Control Center:
Fix Released
Status in webapps-sprint:
Fix Committed
Status in account-plugins package in Ubuntu:
Fix Released
Status in gnome-control-center-signon package in Ubuntu:
Fix Released
Status in account-plugins source package in Xenial:
New
Status in gnome-control-center-signon source package in Xenial:
New
Bug description:
This bug is related to bug 1547647, even though it makes sense in any
case.
Currently, the ApOAuthPlugin class in libaccount-plugin gets the
username from the SignonIdentity, which in turn gets it from signon-
ui, which in the current WebKit1 implementation gets it from the DOM
of the login webpage. This is a hack, it's fragile, not trivial to
port to the Oxide web engine, and possibly against some providers'
guidelines.
We should retrieve the username using some REST API provided by the
service, and in order to do so we need to extend libaccounts-plugin
with some hooks which subclasses can use to get the username.
Once we fix this we can also get rid of the files /etc/signon-ui
/webkit-options.d/, which are conflicting with those installed by the
KDE account plugins packages.
SRU information
===============
[Impact] The same file /etc/signon-ui/webkit-
options.d/www.facebook.com.conf is installed by the account-plugin-
facebook package (used by Unity) and by kaccount-providers (used by
KDE). See this bug's duplicates to see actual bug reports.
[Test Case] Install both account-plugin-facebook and kaccount-
providers and you'll get the conflict.
[Regression Potential] Users running KDE will be completely unaffected
by this. Users running Unity might see a change when creating accounts
in System Settings->Online Accounts: with this bugfix, the account's
display name is obtained by making a REST API call to the remote
service, rather than by scrapping the DOM of the server webpages
(which is a hack, and prone to errors if the providers' webpage
changes). The new way of retrieving the username is the proper one,
and it's been tested to work reliably. In any case, the worst thing
that might happen is that accounts get created with an empty display
name, which is mostly an aesthetic problem (the display name is used
only for UI purposes).
To manage notifications about this bug go to:
https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
