Bug 1119454 (password-recipes)

Support per-sites recipes for capturing and filling the user's login credentials

NEW
Unassigned

Status

()

Toolkit
Password Manager
3 years ago
7 months ago

People

(Reporter: ckarlof, Unassigned)

Tracking

(Depends on: 4 bugs, {meta})

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox ?)

Details

(Whiteboard: [passwords:recipes])

Attachments

(1 attachment, 1 obsolete attachment)

12.26 KB, text/plain
Details
(Reporter)

Description

3 years ago
The password manager uses a set of imperfect heuristics to capture and fill users' login credentials. Although we strive for these heuristics to work on as many sites as possible, they will unfortunately do the wrong thing sometimes. 

From past experience, I've found that having a lightweight, maintainable "recipes" system in the password manager can help both devs and end users fix errant sites.

Some of things recipes can help with:

* explicitly specifying the username or password field for a site (when our heuristics identify the wrong one)
* explicitly specifying what is *not* a username or password field (similar problem to above, but a different solution)
* supporting multi-stage logins (username on first page, password entry on second)
* supporting multi-domain realms (multiple domains that use the same login credentials)
* supporting multi-realm domains (e.g., mailman)
* supporting sites that require multiple usernames to log in (e.g., email and subscriber ID for a health insurer)
* supporting sites that use multiple password fields to log in
(Reporter)

Comment 1

3 years ago
We'll need to decide on how we'll specify recipes. My previous project specified them in a YML file with a list of entries of the format <domain>: <config>.

For informational purposes, I've attached that file to this bug. Take it with a grain of salt. The documentation in the comments is probably more useful than the actual configurations. Also, my previously project was trying more "ambitious" things, like form auto-submit and overlaying our own UI over the site's login form. There some recipes supporting that functionality which are likely going to be irrelevant.

(Lesson learned: don't try to do auto-submit "forms" and don't try to alter the UX too much on the page. It's too fragile.)
(Reporter)

Comment 2

3 years ago
Created attachment 8546161 [details]
recipes.yml
(Reporter)

Updated

3 years ago
See Also: → bug 348941
(Reporter)

Updated

3 years ago
See Also: → bug 589628
(Reporter)

Updated

3 years ago
See Also: → bug 494593
(Reporter)

Updated

3 years ago
See Also: → bug 443800
(Reporter)

Updated

3 years ago
See Also: → bug 209423
(Reporter)

Updated

3 years ago
Depends on: 1119507
(Reporter)

Updated

3 years ago
No longer depends on: 1119507
(Reporter)

Comment 3

3 years ago
Recipes to fix issues with HTTP Basic Auth and Digest Auth would also be handy.
(Reporter)

Comment 4

3 years ago
Given the amount of noise in the initial attachment, I've pruned it down a bit to what's relevant.
(Reporter)

Comment 5

3 years ago
Created attachment 8546753 [details]
recipes.yml
Attachment #8546161 - Attachment is obsolete: true
Blocks: 348941
See Also: bug 348941
Depends on: 1120129
(In reply to Chris Karlof [:ckarlof] from comment #0)
> * explicitly specifying the username or password field for a site (when our
> heuristics identify the wrong one)
> * explicitly specifying what is *not* a username or password field (similar

I broke this part down into bug 1120129 so I can start making it block website bugs which will need that type of recipe.
(Reporter)

Updated

3 years ago
Depends on: 1120684
(Reporter)

Updated

3 years ago
See Also: bug 494593
(Reporter)

Comment 7

3 years ago
:dolske raised the following point on IRC and I think it's a good one:

12:53 PM <@dolske> ckarlof: one thing we might want to consider for recipees... I wonder if we should have the ability for a recipee's domain to not be just a site (ie, literal DNS domain) but also something detected on any page.
12:54 PM <@dolske> the specific case I'm thinking of is mailman.
12:54 PM <@dolske> (although it might not be a great example)
12:55 PM <@dolske> being able to make a login specific to a particular path is needed there. If the recipee for doing that was per-host, it would grow to be a gigantic list. Having a "for pages that look like mailman, do this" kind of recipee would be useful.
(Reporter)

Updated

3 years ago
Priority: -- → P1
(Reporter)

Comment 8

3 years ago
This is ready to break down.
(Reporter)

Comment 9

3 years ago
A recipe to support our Okta SSO would be a good starting place.
Assignee: nobody → MattN+bmo
Status: NEW → ASSIGNED
Flags: firefox-backlog+
Hi Matt, can you provide a point value.
Iteration: --- → 38.2 - 9 Feb
Flags: qe-verify-
Flags: needinfo?(MattN+bmo)

Updated

3 years ago
Iteration: 38.2 - 9 Feb → 38.3 - 23 Feb

Updated

3 years ago
Points: --- → 5
Flags: needinfo?(MattN+bmo)
Assignee: MattN+bmo → nobody
No longer blocks: 348941, 1118955
Status: ASSIGNED → NEW
Iteration: 38.3 - 23 Feb → ---
Points: 5 → ---
Depends on: 348941, 1134530
Flags: qe-verify-
Flags: firefox-backlog+
Keywords: meta
Priority: P1 → --
Summary: Breakdown: Support per-sites recipes for capturing and filling the user's login credentials → Support per-sites recipes for capturing and filling the user's login credentials
Alias: password-recipes
Depends on: 1134846
Depends on: 1134850
Depends on: 1134852
Depends on: 1134859
Release Note Request (optional, but appreciated)
[Why is this notable]: Improved capability to manage passwords.
[Suggested wording]: Not sure yet. Depends on what sites we have ready when we launch this feature
[Links (documentation, blog post, etc)]:
relnote-firefox: --- → ?
Depends on: 1145754
Depends on: 1159538
See Also: bug 589628
Whiteboard: [passwords:recipes]
Depends on: 1330829
You need to log in before you can comment on or make changes to this bug.