213376 - Password list should display the HTTP auth realm as a separate column

Status: NEW

(Thunderbird :: Preferences, enhancement, P5)

Description

[odi]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612

When saving passwords for hosts with many authentication realms, the password
manager list is really difficult to maintain without knowing the realm the
password was saved for. The list should contain an additional column that
contains the realm (for passwords that have one).

Reproducible: Always

Steps to Reproduce:





I know the password manager is generic and not only used for HTTP
authentication. However the password manager's intent is to *manage* passwords
and not just display a list.
We are a web design company and have a staging server for client's projects that
are password protected by individual passwords. Some of them are web apps with
user management as well. So there are dozends of passwords to manage. Without
the realm name this is virtually impossible.

Comment 1

[Bill Mason]

RFE, not a bug.

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

The password manager does show the realm. Look at the site column.
It shows: "www.domain.com:80 (Realm)"

Comment 3

[Jo Hermans]

It's still a sensible request, especially now that we will be supporting the
domain for the NTLM authentication. They're similar enough.

See also bug 140589, bug 131913 and bug 179576. Shouldn't we fix all 4 together ?

Comment 4

[odi]

I see that the realm is shown in brackets. Still I think it's not very readable
like that. A separate column would be nice.

For webapps that perform form authentication (no HTTP realm available), showing
the path to the webapp as the realm would also greatly increase usability!

For two webapps under www.dot.com/app1/ and www.dot.com/app2/ with user1-3 for
app1 and user4-6 for app2 currently the list looks just like:

www.dot.com       user1
www.dot.com       user2
www.dot.com       user3
www.dot.com       user4
www.dot.com       user5
www.dot.com       user6

But I can not distinguish the application. It gets even worse if you have equals
usernames (but different passwords) in two applications, like "admin", which is
very frequent. Thanks for looking into this.

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 7

[odi]

This is still a problem.

Comment 8

[u279076]

Ok...this enhancement has been sitting here unconfirmed for far too long.  Could we get a developer to look at this and see if it is feasible to do what the reporter suggests?  or are we just going to keep doing it the way we are doing it?

Right now, for ldap, the store is:  <domain>:port (realm)

Thanks.

Comment 9

[Tony Mechelynck [:tonymec]]

SeaMonkey trunk Password Manager is currently being ported to a new backend. I'm adding a dependency here because it's no use writing this kind of enhancement on the "old" backend.

Comment 10

[Tony Mechelynck [:tonymec]]

Neil: I think you're the guy to decide what to do with this bug; and if I'm mistaken, I guess you know whom to CC... See comment #8 and even more, comment #0.

Comment 11

[[e-mail]]

Justin Dolkse will be able to tell us if it is likely that the toolkit password manager is likely to support this RFE. (Note that even if SeaMonkey does use its own password manager we would probably want to reuse as much of the toolkit password manager as possible which would include the available columns.)

Comment 12

[Justin Dolske [:Dolske]]

From the bug summary, this should already be fixed (in the toolkit password manager) -- the realm is always shown. I'm not sure exactly what wallet did, although comment 2 implies it did the same thing.

But it sounds like what's *really* being requested is to show the realm in a separate column, instead of just the single-column "hostname (realm)" format. That could be done now, and I'd take such a patch. It would be nice to show the formSubmitURL too (perhaps in a hidden-by-default column).

Comment 13

[Robert Kaiser]

Hrm, now that Philip moved it to toolkit, I might need to file a new one for SeaMonkey's new UI (Data Manager)...

Comment 14

[Robert Kaiser]

(In reply to comment #13)
> Hrm, now that Philip moved it to toolkit, I might need to file a new one for
> SeaMonkey's new UI (Data Manager)...

And that's bug 617588 now.