Open Bug 1134859 Opened 10 years ago Updated 2 years ago

Support domain wildcards in password manager recipes

Categories

(Toolkit :: Password Manager, enhancement, P3)

enhancement
Points:
5

Tracking

()

People

(Reporter: MattN, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [passwords:recipes])

There are times when we may want a recipe to apply to all subdomains of a domain (e.g. *.okta.com) so it would be good if we didn't have to enumerate all of the subdomains we know about in the recipe.

We should probably make sure that wildcards aren't for a whole eTLD (e.g. don't allow *.co.uk).

Some things to decide:
* How do we know which recipe to use when there are multiple e.g. if there are recipes for a.sub.example.com, *.sub.example.com and *.example.com and the user is on a.sub.example.com.
** Proposal 1: Let each recipe hook/method decide what to do. e.g. for username/password field overrides we may want to use the most-specific field override that applies
** Proposal 2: Only consider the most-specific recipe (regardless of the type of hook being considered). Example: if a.sub.example.com doesn't specify a username field override but has a different override (e.g. for multi-stage) while *.sub.example.com has a username field override. We wouldn't use the username field override since we already found a recipe that applied to our form.
* How do we handle multiple recipes for the same host but with different path regexes? Longest match? e.g. different overrides for a login page vs. a registration page.
Flags: qe-verify-
Flags: firefox-backlog+
Whiteboard: [passwords:recipes]
Priority: -- → P3
Blocks: 1631479
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.