Enable password manager to group entries (sharing same login)

NEW
Unassigned

Status

()

Toolkit
Password Manager
--
enhancement
9 years ago
5 months ago

People

(Reporter: Boris 'pi' Piwinger, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [passwords:heuristics])

(Reporter)

Description

9 years ago
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

9 years ago
Component: Passwords & Permissions → Password Manager
OS: Windows Vista → All
Product: SeaMonkey → Toolkit
QA Contact: privacy → password.manager
Hardware: x86 → All
Recipes could help with this.
See Also: → bug 1119454
Duplicate of this bug: 675273
See Also: bug 1119454
Depends on: 1120684
I created a specific bug for authentication realm recipes. This bug is now blocked by that.
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).
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!).
Duplicate of this bug: 1266940
Whiteboard: [passwords:heuristics]
You need to log in before you can comment on or make changes to this bug.