Open
Bug 494593
Opened 14 years ago
Updated 6 months ago
Enable password manager to group entries (sharing same login)
Categories
(Toolkit :: Password Manager, enhancement, P3)
Toolkit
Password Manager
Tracking
()
NEW
People
(Reporter: 3.14, Unassigned)
References
(Depends on 1 open bug)
Details
(Whiteboard: [passwords:heuristics])
The typical situation in a company network is that you have a bunch of intranet and extranet hosts (the former may or may not be associated with a domain name). Employees will have the same login on all those sites. Once they change their password, in SeaMonkey they will have to modify all entries one by one. It would be a great enhancement if you could link in password manager entries belonging together, so that they would share the same login/password. This request is similar, but not identical to bug 92966, not sure about bug 153986. I believe there was another bug requesting to do it like IE when you find hostnames which are not FQDNs which would help (yet not completely) here. pi
![]() |
||
Updated•14 years ago
|
Component: Passwords & Permissions → Password Manager
OS: Windows Vista → All
Product: SeaMonkey → Toolkit
QA Contact: privacy → password.manager
Hardware: x86 → All
Updated•8 years ago
|
See Also: password-recipes →
Comment 3•8 years ago
|
||
I created a specific bug for authentication realm recipes. This bug is now blocked by that.
Comment 4•8 years ago
|
||
I think recipes will mostly solve this, but we'll still want to think about what to do with the logins themselves. EG: * Recipes will allow using foo.site.com logins with bar.site.com, but do we want to actually record that data in the login? (I'd think not, because sites and recipees will be more fluid than stored logins.) * For existing pre-recipe logins, people with have existing duplicate entries. (eg, I have dozens of *.mozilla.com LDAP logins). Do we attempt to clean up the mess? * Seems inevitable that we'll need to ungroup entries somehow? (Due to mistakes, or changes in a domain's policy).
Comment 5•8 years ago
|
||
Yeah, I don't think we want to couple this information with the actual login data. The login data will indicate the source of the login credentials, and some other information (e.g., a realm table) will signal how it should be used. As you pointed out, we're going to need to change and evolve this mapping over time, and we shouldn't need to munge the user's saved login credentials directly to make updates to realms (e.g., imagine if the user is using master password!).
Updated•6 years ago
|
Whiteboard: [passwords:heuristics]
Updated•3 years ago
|
Priority: -- → P3
Updated•6 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•