Closed Bug 97778 Opened 23 years ago Closed 23 years ago

Auth dialog keeps appearing

Categories

(Core :: Networking: HTTP, defect, P2)

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9.8

People

(Reporter: ccarlen, Assigned: darin.moz)

References

Details

1. Go to a site which requires login with username and password
2. Enter the info if not pre-filled (It was pre-filled for me)
3. Click OK
4. The dialog goes away and pops right back. It does this repeatedly until I cancel.

Stepping through the single-signon and prompt service code, everything was in
order there - http got back the right info from the user.

I think this should be a smoketest blocker - though it passes the B.24 test
because you can't actually log into that site - it's not real.
Tracy - this should fail the EM.15 smoketest. With mfcEmbed, I'm getting endless
username/password dialogs.
Keywords: smoketest
yes, I have seen this, It started Wednesday.  I thought the EM.15 test site just 
wasn't working 'cause I could do the B.24 test.  Upgrading this to blocker.
Severity: critical → blocker
Confirmed.. it looks like this happens with some FTP sites too
Severity: blocker → critical
Ryan, any reason this was downgraded?  "Smoketest critical" doesn't do much
good.  Back to blocker for now.
Severity: critical → blocker
Whoops, sorry!  I don't remember changing it. (Although it appears I did,
looking at the 'Bug Activity').

 I must have inadvertently changed it when I added to CC..  sorry about that!
OR, I could claim it was the new Bugzilla  ;)

Either way, I agree that it is a blocker

** checks to be sure 'blocker' is showing, and presses 'commit' **
-->darin
Assignee: neeti → darin
investigating...
I tested todays build, and http auth worked fine. Is this mfcembed only ? Test
case I used was:

Netscape Internal url: http://status.mcom.com/test/realm/test
WORKSFORME 2001/8/31/08 under linux.
WORKSFORME under winnt using a mozilla build from yesterday
WORKSFORME using mfcembed under winnt from yesterday's mozilla build.
WORKSFORME winnt build 2001/08/31/03, testing mozilla
resolving WORKSFORME... ccarlen, the behavior you noted is consistent with an
entering an invalid password.  are you sure you entered the correct password? 
are you sure the site you are testing accepts BASIC auth?
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
It's the site from the embedding smoketests. The site supports basic auth and
the password was correct - unless it was just changed (possible). I believe the
WFM and I'll look into this - sorry.
ok.. with tever's help i've figured out what the problem is here.

if you type in a URL which requires basic auth, then you'll be asked to enter
your password _twice_.

if however you click on a link to a URL which requires basic auth, you'll only
be asked _once_ for your password.

reopening, with severity critical
Severity: blocker → critical
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
after further investigation, the problem appears to be the following:

1) request http://planetoid.mcom.com/realm
2) enter credentials [username=foo, password=foo]
3) web server responds with 301 redirect to /realm/
4) /realm/ is requested without credentials
5) web server responds with 401
6) we prompt user a second time

this is with apache 1.3.14

the user credentials should be stored in the auth cache, and they should be sent
in step 4.

investigating...
ok, the problem is not exactly what i thought...

when i first request the URL http://planetoid/realm
i get a 401 and store authentication credentials for host=planetoid

upon 301 redirect, the URL changes to http://planetoid.mcom.com/realm/
and for host=planetoid.mcom.com there are no cached auth credentials.

thus, the user is re-prompted.

this problem has been with us FOREVER... removing smoketest keyword, and
reducing severity to major.

the solution to this problem likely involves resolving the host to the FQDN
-> mozilla 0.9.5
Severity: critical → major
Keywords: smoketest
Priority: -- → P2
Target Milestone: --- → mozilla0.9.5
i have a patch in mind that involves exposing the FQDN via nsISocketTransport. 
this would then allow http to record the FQDN in the auth cache.
Whiteboard: critical for 0.9.4
is this really "critical for 0.9.4"?
Status: REOPENED → ASSIGNED
oops, I thought this was browser. please excuse the noise.
Whiteboard: critical for 0.9.4
-> 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 61681
Target Milestone: mozilla0.9.6 → mozilla0.9.8
-> 0.9.8
the id/password for the link (http://browsertest.web.aol.com/tests/private) 
smoketest EM.15 must have been changed/expired. Does anyone know a valid 
id/password for this test?   Or perhaps suggest another page to substitute in to 
be able to run the test completely?  The links given in comments above are not  
found.  Thanks.
Tracy, soon after I filed this bug and then found that the password had changed,
I contacted mdunn and asked to have a new URL (that was actually ours) set up
with which we could test this. Micheal, any news on this?
conrad: is this still a problem in recent nightly builds?
When I reported this, I believe the problem was that the username/password for
the site in the smoketests changed - which made this invalid. I've asked that we
get a new one and that hasn't happened, so I don't know.
marking WORKSFORME, since i cannot reproduce any similar problem using a recent
build.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
marking verified

Conrad, please let me knwo of another test case to exchange with for the embed 
smoketesting.  Just let me know the link and I'll update the smoketest page.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.