User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+ After changing the username of an account, the password-manager still shows the old name Reproducible: Always Steps to Reproduce: Try this: 1. Generate an new account 2. get messages for account 3. click "save password" 4. change user-name of account 5. get mail 6. check "save password" 7. goto peferences/password 8. lock at the user-name ... some funny ... 9. delete the "old" user-name 10. restart thunderbird 11. get mail with new user 12. click "save pw" 13. goto prefs/pw-mgr 14. ... and see the old user-name again ... ???

Can you reproduce this problem in the latest trunk build of Thunderbird? http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/

Reproduced steps 9-14 with: thunderbird-1.0+.en-US.win32.installer_2005-07-27-08-trunk.exe

Server name and user-id on account definition is saved in mail.server.serverNN.hostname / mail.server.serverNN.userName, and are used for mail directry name default, internam mail folder path name and so on. When server name / user-id is changed, they are saved in mail.server.serverNN.realhostname / mail.server.serverNN.realuserName, and mail.server.serverNN.hostname / mail.server.serverNN.userName are kept as initial value. This realhostname / realuserName are used in login(If not exist, hostname/userName are used.) This is because hostname / userName are already used for internal mail folder path name and the internal path name is used in many other places, such as message filter, then not changeable. I think hostname / userName are also used as "key" in password manager. It is not a bug, because it's an internal "key" for password management, but it tends to produce user's confusion. I prefer using realhostname / realuserName as "key" for password manager.

This is indeed confusing, the work going on for bug 239131 should fix this.

(In reply to comment #5) > > *** This bug has been marked as a duplicate of bug 239131 *** > Nikolay, this is not a duplicate of bug 239131. Whilst I think the work on bug 239131 should fix this, if for some reason it doesn't, then we need to revisit it - that is why I added the dependency.

ludo, do we have someone in security or accounts area to test this, if you can't? (In reply to Mark Banner (:standard8) from comment #6) > (In reply to comment #5) > > > > *** This bug has been marked as a duplicate of bug 239131 *** > > > > Nikolay, this is not a duplicate of bug 239131. Whilst I think the work on > bug 239131 should fix this, if for some reason it doesn't, then we need to > revisit it - that is why I added the dependency. LV-Crew is gone, and the above bug is fixed

So tried this - but the new password isn't saved as the second account name I entered was invalid.

I have noticed this too when poking other bugs with keeping the account passwords. This still exists. Yes it is confusing to the user. Yes, we store the original hostname and username as the identifiers in the password manager, even though we send the current (real) username to the current (real) hostname. This is easy for us as it is the serverURI which we use in many places (even though for the password identifier we strangely duplicate the code). Can anybody see any problem if we switch to using realHostName and realUserName in the password manager? Some notes: 1. we already prevent having 2 servers with the same hostname and the same username (in the AM UI). So after the switch we should not get collisions. 2. if we switch, do we want to migrate the existing passwords? 2a) Like see if the is a password with the old method and migrate to the new method (identifier). In this case we could get collisions (some old hostname of one server may now we the new hostname of another server). But if it fails, we just do not send the correct password to the server and user has to retype it and things get sorted. 2b) If we do not migrate, some users may have to retype the password for their server if they changed host/username in the past. 3. we also set the HTTP realm attribute of the stored entry to the same serverURI as we use for the hostname (see definition of the interface at https://dxr.mozilla.org/comm-central/rev/b7f895c1dc2e91530240efbf50ac063a0f8a9cb5/mozilla/toolkit/components/passwordmgr/nsILoginManager.idl#177) so it looks ugly in the password manager, e.g. "mailbox://a.b.c (mailbox://a.b.c)". If changing the hostname (the serverURI) proves problematic, we can at least set the HTTPrealm to the current hostname. Wayne, do you think there may be bug reports due to this? Users checking the password manager and wrongly thinking their password IS/ISN'T stored due to seeing incorrect server/username?

> Wayne, do you think there may be bug reports due to this? Users checking the password manager and wrongly thinking their password IS/ISN'T stored due to seeing incorrect server/username? You mean "other" bug reports, or support requests? I can't think of any off the top of my head. I should think renames would be rare, but have no data to back that up. That said, I queried bugzilla https://mzl.la/2f0wUB5 which is worth skimming to see the range of issues, both fixed and not. Bug 561056 pops up, which you know about.

I'm for using the new username to not confuse the user later, when he doesn't remembers he changed the username, with a username that doesn't fit the actual state. Also the migration should be done if possible.

I can't think of any problems with this. The original hostname and username are used to uniquely identify the account, so it was necessary that they did not change (and shows that using them as a unique identifier was a bad idea in the first place). But password lookups IMHO really should use the actual name and host. "2. if we switch, do we want to migrate the existing passwords?" Yes that would be good.