637292 - Password Manager API

Status: RESOLVED DUPLICATE of bug 610607

(Add-on SDK Graveyard :: General, defect)

Description

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Implementing API for a password manager.

Comment 1

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Attachment: Documentation that serves as an API proposal.

Comment 2

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

I've put together documentation MD and created a pull request. Please note that I don't ask to pull in the change, I just ask for a feedback on the proposed API.

Comment 3

[Dietrich Ayala (:dietrich)]

Thanks Irakli! Can you post this on the original password manager API bug?

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 515652 [details]
Documentation that serves as an API proposal.

This looks great.  The API is explicitly asynchronous, which is different from our other high-level APIs, but it accesses data stored in an SQLite database, which can potentially take a long time, so the asynchronicity makes sense, and it is consistent with the proposed Places API (which also accesses SQLite data) in bug 545700.

There are a few minor naming issues:

* The module should be called `passwords`, which is the simplest obvious name for it, is the most accurate name (as the API exposes credentials that may or may not include usernames but always include passwords), is consistent with the naming and description of the feature in the Firefox interface, and is consistent with the naming of other high-level APIs (although, unlike those other APIs, its exports object is not iterable, a potential downside of this name).
* `onDone` should be called `onComplete`, which is consistent with the Request and proposed Places APIs and is also more common in other JavaScript libraries.
* `user` should be called `username` (and `userField` `usernameField`), which is a more common name for such data.
* `find` should be called `search`, which is consistent with the proposed Places API.

Finally, note that the three primary use cases for this API to support, in order of priority (from higher to lower), are:

1. Retrieve credentials for a website, so the addon can access the user's account on the website and retrieve information about the user.
2. Store credentials that are associated with the addon rather than a particular website, so the addon can access them in subsequent sessions.
3. Store credentials that are associated with a particular website so both the addon and the user (when visiting the site without the addon) can access them in subsequent sessions.

Thus the documentation should describe the `search` method first and the most thoroughly.

A few more notes:

* If the `url` value includes a path, we should strip it out automatically.
* When an addon stores a password that is not associated with a particular website, the password should be associated with the addon itself (f.e. by automatically setting the URL of the password to a chrome: or resource: URL that uniquely identifies the addon).

Comment 5

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Attachment: Pointer to pull request