130638 - Password Manager doesn't correctly fill in passwords since 0.9.9

Status: RESOLVED WORKSFORME

(SeaMonkey :: Passwords & Permissions, defect)

Description

[Lars Marowsky-Bree]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
(I had to use an older Mozilla to file the Bugzilla entry because I couldn't
remember my bugzilla password ;-)
BuildID:    20020310

The Password Manager doesn't correctly fill in passwords it has stored in its
database for some sites since 0.9.9. It worked perfectly with 0.9.8.

It appears to be related that the URL it has stored the password for is not
correctly normalized. ie, some are stored with http:// prefix, some with :80
postfix, some just the plain hostname etc.

Passwords which are saved again are correctly filled in the next time; however,
as Mozilla still has no option to actually _view_ the stored passwords in clear,
this is quite annoying work.

This means I lose access to my stored passwords, which is why I am filing this
bug as critical.


Reproducible: Always
Steps to Reproduce:
1. Go to a few sites which Mozilla prior to 0.9.9 has stored a password for.
2. Check whether 0.9.9 will fill it in.
3.

Actual Results:  For reasons I haven't clearly identified yet, some work, some
don't.

Expected Results:  Should work every time.

Comment 1

[Stephen P. Morse]

I'll bet that this is related to bug 130583 and bug 130545.  Both are recent 
regressions and both deal with sites that use explicit port numbers.  Nothings 
changed in this area in either cookies or password-manager, so it's probably due 
to a change that occured upstream from both.

Comment 2

[Lars Marowsky-Bree]

Formfill with passwords appears to be working all the time; the bug appears to
only appear for http auth. Sometimes, it can be circumvented by going to
http://foo.com:80/ instead of http://foo.com/.

Comment 3

[Mike Shaver (:shaver emeritus)]

I think it was this checkin that did it (darin's instincts in the follow-on bug,
127863, are spot on):

1.88 badami%netscape.com
Feb 12 02:53
Add port to auth prompt only if it was mentioned on the URL bug 95350 r=morse
sr=darin

On the trunk, we now have this checkin:

1.95 <[e-mail]> 11 Mar 2002 05:25
regression in removing invalid passwords from password manager
bug 127863 r=morse sr=darin a=asa

which might fix it?  Someone should test, I imagine. Either way, we need to make
sure that 1.0 can handle data in the pre-0.9.9 and 0.9.9 formats, preferably by
migrating them forward to the new format.  Steve, can you give us a fix for that
part soon?

I'm going to plus this bug, and someone might want to nsbeta it: it'll be
required, I believe for compatibility with NS6.2 users in MachV or whatever the
next Netscape release is.

Comment 4

[Darin Fisher]

ouch!

Comment 5

[Stephen P. Morse]

It looks like the fix reverted back to the original format being stored by the 
password manager.  Is that correct?

If so, the only people that will be affected are those that saved some passwords 
with 0.9.9.  Any passwords that they saved with 0.9.8 and earlier are OK, and 
any saved with a nightly after the second fix went in are OK.  And that means 
that N6.2 users are also OK.

Do we really want to support the very temporary 0.9.9 format by adding extra 
code in the 1.0 release?

Comment 6

[Lars Marowsky-Bree]

Providing a tiny tool to fix up the data and pointing to it in the next relnotes
should be enough.

If I looked correctly, that tool wouldn't even need to decrypt any data, since
only the user/password combo is encrypted and not the site info.

Comment 7

[Mike Shaver (:shaver emeritus)]

Well, you're the password expert, but I haven't saved any passwords in 0.9.9 yet
and I have a pile of port-less hosts in the password manager, and the trunk sure
looks like it always puts the port in the passwordRealm.  Given that "we" have
made it so that you can't actually see the saved passwords in the password
manager, it seems like this is a pretty serious issue.

We put 0.9.9 out to get it tested, so telling people "hey, don't save any new
passwords because you'll lose them on the upgrade, and you can't even copy them
out by hand" seems pretty bad.  A dataloss bug, one might say, though we don't
usually create those _on_purpose_.

Even if the format is "only" for 0.9.9 -- a branch which is being targetted by
many embedding and downstream customers -- the amount of code to detect a
port-less URL and fix it up is likely to be trivial.  On the order of 10 lines
of code, unless I miss my guess.  And while you're in there, you could look at
the O(number-of-stored-passwords) behaviour of password lookup as well.

lmb: writing a tool to fix up the data is likely much harder than just fixing
this in Mozilla, because we'd have to provide it for many platforms.

Comment 8

[Vinay Badami]

Yes, the format is reverted abck to original. The only people who will get
affected are people who would save username/passwd with 0.9.9.

Options:
1. If we are continuing 099 for embedding etc, then i suggest that we checkin
the patch that is on the top onto 099 branch as well.
2. I think that we can fix this in nshttpchannel.cpp by first trying with the
standard format and then without the port if the port was the default one based
on http/https. This will help to take care of 099 users too. Need to look a bit
further at the code to confirm this. However, not sure if we really want to do
this and carry the legacy forever or just document it. The only result would be
that the user would be forced to type in his username/passowrd again and it
would get stored the correct way. Else, he can edit the file and add in :80 or
:443 based on whether the site was secure or not. Agreed it is dataloss but i
think that the magnitude/scope is limited.

I do not see how this fix could have triggered anything to do with cookies as
reported in bug 130583. It could have only affected http auth stuff.

Suggestions/Comments ?

Comment 9

[Lars Marowsky-Bree]

Editing the file is something I can certainly do. However, how many average
end-user people have picked up Mozilla 0.9.9 for the first time?

The point about the legacy code is well made though.

If I were you, I would document the two choices (either fix up the file manually
or reenter some passwords) very clearly in the next relnotes and be done with it.

On the other hand, a general consistency check in the parser of this file -
which would notice such wrong entries, surely - is something which also appeals
to my developer heart - fortify your subsystems ;-)

The choice is yours.

Comment 10

[Stephen P. Morse]

reassigning to badami to either check his patch into the 0.9.9 branch or make 
the necessary fix to nsHttpChannel.cpp as he described.

Comment 11

[Stephen P. Morse]

*** Bug 130861 has been marked as a duplicate of this bug. ***

Comment 12

[Stephen P. Morse]

*** Bug 130329 has been marked as a duplicate of this bug. ***

Comment 13

[Andrew Treloar]

I'm seeing a possibly related issue with all builds since 0.9.9 under OS X. When
I  access an external page via our proxy server (using http basic auth) I get
asked to authenticate for *every* external page, even though I select 'Remember
this password' in the dialog box. It is neither remembering the password nor
caching it. This essentially makes Mozilla unusable for me and for all those at
my university until this is fixed.

Comment 14

[Vinay Badami]

 Andrew Treloar 
Can u please pick up a nightly build and verify that all if ok for you on the tip ?

Comment 15

[Lars Marowsky-Bree]

Running a 20020318 build right now, and at least for me, the PM appears to be
working correctly again.

Comment 16

[Stephen P. Morse]

*** Bug 132194 has been marked as a duplicate of this bug. ***

Comment 17

[Mike Hatz]

I am assuming that this is related to the fact that when I click on the "Manage
Stored Passwords" button - absolutely nothing happens.  No sites.  No passwords.
 Just an hour glass that runs for a bit and quietly dies.

Win 2000/SP2 running 0.9.9

Comment 18

[Darin Fisher]

mass move of bugs assigned to vinay to me

Comment 19

[Darin Fisher]

reporter (and those cc'd): do we still have a bug here?  if so, can someone
summarize the current problem(s)?  thx!

Comment 20

[Andreas Otte]

Maybe it should be relnoted that passwords captured with 0.9.9 need a little bit
of hand editing in the password file before being useable again, but otherwise
this is fixed.

Comment 21

[Daniel Rogers]

This seems fine in RC1 with my passwords from 0.9.8

Dan.

Comment 22

[Darin Fisher]

adding relnote keyword...

benc: can you see to it that a relnote for this bugs gets added to mozilla 1.0?

Comment 23

[Lars Marowsky-Bree]

It is fixed for me.

Comment 24

[benc]

Darin: I'm going to leave that to Terri, if she wants to. QA doesn't write
release notes, I just do that for networking bugs because I feel obligated since
mozilla and netscape like to surpress networking info from end users. I had a
long-term goal of eventually publishing "fully annotated networking release
notes" (or something to that effect), which is why I keep using relnote kewyord
even though it's officially deprecated by the docs teams in CPD.

Comment 25

[Darin Fisher]

mass futuring of untargeted bugs