Closed Bug 131913 Opened 22 years ago Closed 13 years ago

Password manager must handle individual pages and ports instead of whole domains

Categories

(Toolkit :: Password Manager, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 444333
Future

People

(Reporter: georg, Unassigned)

References

Details

The password manager must handle individual pages instead of domains. If a
domain contains multiple forms with password fields then There is no reason, why
they should be filled all equal. They are individual forms that require
individual collected data to be managed by the password manager. This data
should be also avialable by the "view saved data" menu. There it should be editable.
Hmm, seems like a bad idea to me. Also, please only mention ONE
issue per bug (read the bug writing guidelines).

See bug 92966 for another side of the coin..
The problem of bug 92966 is an other problem. To solve both, the user should be
asked how to manage the form data. I the actual situation I must disable the
password manager completely because it overwrites the default values of the form
fields by it's stored data from other forms. This is not nice.

Is there any chance to prevent this problem by renaming the form fields? I.e.
giving each form element requiring an individual content a domain wide unique
name? If I as web developer can influence the behaviour of Mozilla by fitting
the naming strategy to the requirements of Mozilla, then this would be at least
one step forward, but doing this requieres more information about how the PWM
works and how such a naming strategy should look like.

A more better solution would be to let the user decide for each form how to deal
the data.
I can't find an obvious dupe.

Confirming as a valid request. Still should be WONTFIXed though...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Take a look to iCab, that can define rules for individual URIs

http://icab.de/
I'm also bit by this. On one domain I have the same username but different
passwords. This not only gives me problem with knowing what password that is
filled in, I also have several "identical" lines in the password manager dialog.
Same site and same username. I have to randomly select one to delete a managed
password (you don't know which you are deleting).
Reassigning to new module owner.
Assignee: morse → dveditz
Status: ASSIGNED → NEW
Two pages on the same server may be completely unrelated. In fact, I think that
with most applications/sites, the user always uses the same URL to login, so
saving a username/password for a whole server should be an exception.

This bug and bug 92966 are both perfectly valid RFE's/bugs, even though they
request opposite behaviour. Therefore, there needs to be an implementation that
allows for both.

Possible solution: Currently, the password manager decides only based on the
hostname. Make it decide based on hostname, port and path, but:
- if an entry's path is empty, use that entry for any URL that matches other
criteria
- if an entry's path ends with a slash, treat is as a prefix
- if an entry's port is not filled in (or is zero), use that entry for URLs with
any port
- if an entry's hostname starts with a dot (or an asterisk, or "*."), treat it
as a suffix.

This would allow for:
- global login in all servers in domain company.com
- separate logins in company.com and intranet.company.com, but common for
intranet.company.com/app1/... and intranet.company.com/app2/... (current behaviour)
- separate logins in geocities.com/user1/... and geocities.com/user2/...

However, the UI for this is a bit difficult. In fact, since this whole concept
may be too advanced for most users to grasp easily, it should probably be hidden
from their view. One of the "modes" should be preselected as the default
(probably the current way so that we don't change behaviour), and there should
be an "Advanced" button in the "Do you wish to save that password?" dialog.
Clicking the "Advanced" button would uncover input fields with the hostname,
port and path. The knowledgeable user could then edit them to make the login
more global or less global. (But making it "less global" [i.e. path-specific]
would require typing the path - not good. Perhaps there should be a button to
"Fill in current page's path".)
OS: Linux → All
Hardware: PC → All
*** Bug 167906 has been marked as a duplicate of this bug. ***
Would anyone be opposed to broaden the scope of this bug to include handling of
different ports for one hostname? (Bug 179576.) It seems like one bug/RFE to me.
I propose changing the summary to explicitly mention both paths and ports:
"Password manager should handle individual pages (paths, ports) instead of sites
(hostnames)".
*** Bug 208358 has been marked as a duplicate of this bug. ***
Blocks: 208616
*** Bug 179576 has been marked as a duplicate of this bug. ***
Changing summary to reflect the different ports issue.
Summary: Password manager must handle individual pages instead of domains → Password manager must handle individual pages and ports instead of whole domains
Product: Browser → Seamonkey
Guys, can we have some action on this bug? I think what is proposed in comment
#7 is eminently sufficient. The last post on this bug was 2003-07-23, over two
years ago today...
The problem with passwords has reduced, because the password manager now can
remember multiple login / password pairs for a domain, providing a choise to
select the correct pair.

So this problem is no longer so important as it was, when I reported it. In that
old days the password manager did not support multiple login / password pairs
for a domain. The actual situation is accecptable as long as the login of all
login / password pairs belonging to a domain is unique. If different pages use
different databases for the login / password pairs, then the login might be
unique for the individual pages, but not unique for the whole domain. But this
happens not very often.
Assignee: dveditz → nobody
This has been bothering me recently, having multiple domains hosted at mail.google.com/a/domain.com.  If I have the same username at two of them (me@domain1.com and me@domain2.com) with different passwords, I can't store different passwords easily in firefox.

It seems like it would be a fine interface to have the "do you want to remember this password" dialog give you options like "Yes, for this URL only", "Yes, for mail.google.com", "Yes, for *.google.com".

Another idea which might be better is to only store passwords by URL, but make it easy to associate new URLs in the same domain with an existing password.  For example, the first time I visit the login form at mail.google.com/a/domain1.com, it stores the username and password.  When I then visit the login form at mail.google.com/a/domain2.com, a dialog pops up and asks something like "Do you want to use the same password as for mail.google.com/a/domain1.com?"  Then, if you say yes (which I wouldn't do in this case, because I want them separate), it points both URLs to the exact same user/pass pair, so if I want to change it in the future, I only have to change it once and it gets updated for all related URLs.  If I say no, but instead store a new password, then it will generate a separate user/pass pair ties only to the new URL, and subsequently when I visit either page, the right username and password get stored.

I'm happy to explain this idea more if it's confusing, but I'm starting to think that it could work pretty well.
That'll teach me to read the details before posting...I actually meant to file this against firefox, but didn't find the right bug.  Sorry for the spam if you're not interested in firefox, and if you know of the relevant bug that would apply to firefox, feel free to pass me a better link.
QA Contact: tpreston
Component: Passwords & Permissions → Password Manager
Product: SeaMonkey → Toolkit
QA Contact: password.manager
this is a dupe of bug 444333 after this got moved to toolkit
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.