Open
Bug 1134859
Opened 10 years ago
Updated 2 years ago
Support domain wildcards in password manager recipes
Categories
(Toolkit :: Password Manager, enhancement, P3)
Toolkit
Password Manager
Tracking
()
NEW
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+
Reporter | ||
Updated•8 years ago
|
Whiteboard: [passwords:recipes]
Reporter | ||
Updated•5 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•