Dbus service for maintaining users' online accounts


We are planning on moving the Bigboard accounts system to a stand-alone Dbus service that other applications can use to collect and retrieve web accounts information. Here are some details of our plan. The org.gnome.OnlineAccounts service will centrally manage all web accounts supplied by the user and store them in a GConf directory, for instance under "/desktop/gnome/online-accounts". It will also store account passwords in the GNOME Keyring. The applications should not need to know the exact details of how and where the accounts and passwords are stored in GConf and GNOME Keyring, since the basic functionality of the OnlineAccounts system would be to put accounts information into GConf and GNOME Keyring for the applications and retrieve it from GConf and GNOME Keyring to supply it to the applications. Within the org.gnome.OnlineAccounts service, there will be an object for central management of all accounts at /org/gnome/OnlineAccounts and objects representing individual accounts at paths such as /org/gnome/OnlineAccounts/OnlineAccount/1.

While OnlineAccounts system will provide methods for adding and removing accounts that the applications can use as the backend for their own UI, we will encourage using the dialog provided by the OnlineAccounts system for collecting information about user accounts. This dialog will have two modes -- one containing all the account types and another one containing only the account types specified by the application. So a photo application would be able to request only the types of photo accounts that it handles to be listed for the user to edit and add new ones. In addition, the version of the accounts dialog that contains all the account types will be available to the user at all times through the Desktop Preferences.

Take a look at the attached screen shots of the current accounts dialog in Bigboard to see how the accounts dialog might look.

When the account is added, removed or disabled, this information will be propagated to all applications. Therefore applications should use the remove and disable account functionality very cautiously and inform the user that this will remove or disable the account from the centralized list of user accounts. If it makes sense for an application to maintain a private status of a certain account as being disabled, it should be done so by the application, along with maintaining other properties for an account it might find useful. The key service of the OnlineAccounts system is to centralize the maintenance of the user credentials for an account, i.e. the username and the password, as well as the desktop-wide status for an account as enabled or disabled. The reason for restricting OnlineAccounts system to just that level of service is that this will allow to maintain a consistent state for the user, while applications can let the user disable accounts through their own UI and make it clear to the user that the disabled status is for the given application only.

The accounts will be backed up online at online.gnome.org whenever the online.gnome.org identity is available for the desktop user. When accounts are being set on the server, we might run certain checks to verify the validity of the submitted usernames, such as verifying the url for the account exists. The accounts dialog might display an error to the user if the username was not saved or a warning if the username was saved, but the account is in the private mode and that might limit applications' access to it. If applications are adding accounts directly, without using the OnlineAccounts system dialog, they should be prepared to handle such feedback.

The set of account types will be maintained at online.gnome.org and will be extensible with application developers being able to enter new account types and information about them. A web interface for adding and editing account types will be available on online.gnome.org. Dbus service and clients will use a short name for an account type submitted through online.gnome.org to identify the account type. A combination of the account type string and the username for the account will uniquely identify an account.

While password entry will initially be shown for all account types, in the future we might provide a dialog mode that allows entering accounts of certain types, but does not ask for passwords. Such dialog would be useful if an application does not require user passwords for the online accounts it works with.

Dbus methods and signals exported by the OnlineAccounts object:

GetAccounts() -- returns object paths of all accounts available for the user
GetAccountsWithTypes(types_list) -- returns objects paths of all accounts available for the user with given types GetEnabledAccounts() -- returns object paths of all enabled accounts available for the user GetEnabledAccountsWithTypes(types_list) -- returns objects paths of all enabled accounts available for the user with given types GetOrCreateAccount(type, username) -- returns a tuple with an object path for the account as the first element, and a boolean indicating if a new account was created as the second element RemoveAccount(account_object_path) -- removes account at the given object path, removes it from online.gnome.org account for the user if one exists OpenDialog() -- opens the dialog with all accounts provided by the user, where the user can enter passwords for the accounts, disable, or remove them; the dialog also has a way for the user to add accounts of all known types OpenDialogForTypes(types_list) -- opens the dialog with accounts of the given types provided by the user, where the user can enter passwords for the accounts, disable, or remove them; the dialog also has a way for the user to add accounts of the given types

AccountAdded(account_object_path) -- emitted when a new account is added
AccountRemoved(account_object_path) -- emitted when an account is removed
AccountEnabled(account_object_path) -- emitted when an account is enabled, including when a new account is added AccountDisabled(account_object_path) -- emitted when an account is disabled, including when an enabled account is removed

Note about signals: if an application is using GetEnabledAccounts() function to get the accounts, it should connect to AccountEnabled and AccountDisabled signals, but not AccountAdded or AccountRemoved signals.

Dbus methods and signals exported by the OnlineAccount object:

GetType() -- returns the account type
GetUsername() -- returns the account username
GetPassword() -- returns the account password
GetEnabled() -- returns enabled boolean status
SetPassword(password) -- sets the account password
SetEnabled(enabled_flag) -- sets a desktop-wide enabled status, but the setting does not affect online.gnome.org user account or other desktops used by the user

Changed() -- emitted when account's password or enabled status changes

New server object GnomeExternalAccountType will be added as a field to ExternalAccount and will have the following fields. We will prime the system with all the external account types that are currently specified in Mugshot.

externalAccountType (one of the types defined for Mugshot and either ExternalAccountType OTHER or None)
shortName -- a short name that must be unique
fullName -- a full name for the account type, such as "Remember The Milk", while the short name might be "rtm"
siteLink -- a link to the site that can provide you with this account
siteUserInfoType -- what is used to identify the user for that service (username, e-mail, etc.) maintainer_id -- online.gnome.org id of the user who added this account type, and can remove it if there are no accounts of that type in the system or edit certain fields, such as externalAccountType, prettyName, siteLink, and siteUserInfoType

Any feedback is welcome!


PNG image

PNG image

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