Re: GNOME Online Accounts 3.34 won't have documents support


On 21/01/19 19:32, mcatanzaro gnome org wrote:
We have a rule though: the account types exposed in
gnome-online-accounts must be used by at least one core application.
It's a good rule because it doesn't make sense to have settings in
control-center for apps that aren't installed by default. So unless we
reverse course and add gnome-documents back to core, the documents
account configuration settings should move from control-center to
gnome-documents itself.

I wrote most of the Ubuntu Online Accounts stuff which was used in the
Ubuntu Phones and is still used in Ubports. I hope that bringing my 2
cents will be of some help.

In Ubuntu Phone, we had the same rule that you wrote above: if no
application can use a certain account, it doesn't make sense for the
system settings to carry an option to create that account. But it
doesn't mean that the functionality needs to be removed: it can just be
hidden in the user interface. In fact, what we have been doing in Ubuntu
was to carry configurations for several online accounts, but show them
only if there was at least one application installed that could use
them. Since most of these authentication methods are either OAuth 1 or
OAuth 2, the "weight" of these configurations is minimal: just a small
JSON file.
As soon as the user installed an application supported by an online
accounts, the option to create the account would appear in the system

Second (as mentioned somewhere else in the thread), about applications
being able to ship their own keys: yes, we support it, and it is indeed
the recommended way of working. We still provide the whole
authentication component, so that the application doesn't need to worry
about OAuth, but only needs to tell us what are its authentication keys
and what OAuth scopes it needs.

The account is created by a system process, and if more applications are
using the same account the user doesn't need to login multiple times: we
set the user context directory in the webview to be per-account, meaning
that cookies are shared across all applications operating on the same
account. Given that the webview is not opened in the application's
process, and that we use apparmor to confine the applications, there's
no way that an application can read the cookies.

Last, but not least: some service providers (IIRC Twitter and Facebook),
explicitly state that using an umbrella application to provide access to
several distinct applications, like GNOME is doing, is a violation of
the terms of usage.
In Ubports, the approach that we try to follow is to let the platform
authenticate using a very "weak" (permission wise) set of keys, just
enough to perform the OAuth login and retrieve some unique ID for the
user (e-mail, typically), which we can then show in the account list so
that the user can tell his own accounts apart.

This has also other advantages:
- should some application (or even the very Ubports) get banned by some
  platform, all the other applications continue to work
- less risk of hitting the API limits


-- - Geek in un lingua international

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]