Closed Bug 637292 Opened 9 years ago Closed 9 years ago

Password Manager API

Categories

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

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 610607

People

(Reporter: irakli, Assigned: irakli)

Details

Attachments

(2 files)

Implementing API for a password manager.
Assignee: nobody → rFobic
Attachment #515652 - Attachment description: Pointer to pull request → Documentation that serves as an API proposal.
Attachment #515652 - Flags: feedback?(myk)
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.
Thanks Irakli! Can you post this on the original password manager API bug?
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 610607
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).
Attachment #515652 - Flags: feedback?(myk) → feedback+
You need to log in before you can comment on or make changes to this bug.