139056 - Mozilla requires re-authentication for every page

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Carl Brewer]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311
BuildID:    1.0rc1

on an SSL secured session, every time we submit a form or request a new page,
mozilla 1.0rc1 requires re-authentication.

This has worked flawlessly since we started testing Mozilla at about 0.9.2, and
this is the first time it's been broken.  I've backed out to 0.9.9 to be able to
use mozilla.

the box is a RH 7.1 linux workstation. I haven't see this problem on my win2k
box yet, but also haven't tested it.

Reproducible: Always
Steps to Reproduce:
1. log in to web page (redirected to SSL site from HTTP)
2. read first page
3. request second page

Actual Results:  browser requests authentication for every page, and doesn't
load images

Comment 1

[Matthias Versen [:Matti]]

Can you try a new profile ? (run "mozilla -profilemanager" and create an
addtional test profile)

wfm with win2k build 20020420..

Do you see that also (sorry the page is in german) :
https://www2.postbank-banking.de/
use the Test Account : Kontonummer: 9 999 999 999 / PIN:11111

Comment 2

[Tom P]

I've been hitting this bug all the time.  I use tabs alot.  Using open in new
tab  presents a security warning for entering a secure page.  Cookies are not
exchanged after dismissing warning.

Example.

I right click a link in a secure page to open in a new tab.  Security warning
pops up.  After dismissing dialog page opens normally.

Right click "save link target as" for a file type of .asc (text with page
breaks) results in redirected to a warning page because cookies are not enabled.
 cookies were being used for authentication.

Comment 3

[Boris Zbarsky [:bzbarsky]]

To http networking

Comment 4

[Tom P]

Confirmed this behavior with rc1 build 2002041711 on win2k.  

Comment 5

[Carl Brewer]

I'm not seeing the same problem with my win2k 1.0rc1 install, it's only
happening with RedHat 7.1

ie: this one works :

Mozilla 1.0 Release Candidate 1
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417

Comment 6

[Carl Brewer]

I'll try the new profile tomorrow when I'm at the RH machine and see if it helps.

Comment 7

[Philip White]

WFM on KDE 2.2.2 with Mozilla 1.0RC1.

Comment 8

[Darin Fisher]

reporter: can you enable some env vars to capture a HTTP log...

  setenv NSPR_LOG_MODULES nsHttp:5
  setenv NSPR_LOG_FILE http.log

if you could attach http.log to this bug report it might help us track down the
problem.  (your passwords won't be written out to the log file.)

Comment 9

[Jason Wood]

I've experienced this problem as well under both W2k and RH7.1 since upgrading
to 1.0RC1.  A backout to 0.9.9 has fixed the problem in both instances.

Comment 10

[Carl Brewer]

Attachment: as requested, http.log from connection to intranet site

Comment 11

[Carl Brewer]

I created a test profile as requested, and am not seeing the problem now.

Is there possibly something incompatible between the profile for 0.9.9 and 1.0rc1 ?

Comment 12

[Darin Fisher]

i'm not sure of what could explain the problem you saw with your older
profile... any chance you ran two instances of mozilla at the same time with
that older profile?  doing so, even once could seriously hork your profile...
i'm not sure how that could even cause this, but i suppose it's a possibility :-/

Comment 13

[Darin Fisher]

from the log file it appears that the images (gifs) are coming back with a
content-type of text/html for some strange reason.  as a result, imagelib thinks
there isn't a decoder available, and i suppose that explains why you didn't see
any images.  were you using some kind of proxy server with your older profile?

Comment 14

[Carl Brewer]

Ok, I've isolated this to a specific preferences setting.

If I set cookies to :

Enable cookies for the originating web site only

I see the failure mode, if I enable cookies from "all", it works.

Our cookie is definatly correct for our intranet site.  We've triple-checked it,
and it works fine with this setting under 0.9.2-0.9.9.

I'm currently using last night's build, see below, and seeing the same problem,
and have for now enabled all cookies, but that's not a Good Thing.  Please fix,
and let me know how I can best assist with the fixing.

Mozilla 1.0 Release Candidate 1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020426

We have a proxy, Squid, and all the web traffic goes via it,but this has not
been a problem in the past with earlier mozilla snapshots.

Comment 15

[Carl Brewer]

this is still happening with build Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.0rc2) Gecko/20020505

Is there anything further I can do to assist the debugging of this, or is it
related to some other bug?  Can someone set the status of this to a confirmed
bug, at least? :)

Comment 16

[Carl Brewer]

this is still broken in 

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510

Comment 17

[Carl Brewer]

this seems to be fixed in 

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523

ie: it's not exhibiting the same broken cookie handling when set to accept
cookies from the originating site only.

Thanks for fixing it :)

Comment 18

[John Unruh]

V