From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-test8 i686; en-US; m18) Gecko/20000918 BuildID: 2000091821 Login via basic auth simply doesn't work. The username and password box pops up alright, but when you hit enter or click OK, nothing happens... The box disappears, but the requested page does not load Reproducible: Always Steps to Reproduce: 1.enter a protected page 2.enter username/password 3.click ok Actual Results: nothing happens Expected Results: The page should be loaded Running through squid 2.3 proxy, in case it should matter...

Looks like a dupe of bug 31174 - "SSL requests not going to proxy". *** This bug has been marked as a duplicate of 31174 ***

It doesn't look like it's got anything to do with that bug... Even if I disable proxy, nothing happens, I only get this error on the console: Error loading URL http://www.cs.auc.dk/cs_network/: 804b0002 Besides, even if I try non-SSL URL's, the result is the same...

I am seeing this as well using Build 2000091906/Linux. I logged into a site earlier in the day, upon returning (following a crash) when prompted with username/password, they were memorized and I clicked OK. Got the following: we don't handle eBorderStyle_close yet... please fix me Error loading URL http://24.112.110.171:9673/circron/: 804b0002 Additionally, I tried clearing the l/p fields from the box and re-entering them manually to no avail. I went to the menu Tasks:Privacy and Security:Pasword Manager:View Stored Passwords and deleted the appropriate entry, and that did not change the situation. Attempted this with other URL's, same issue: worked once, won't work additional times, even after restarting the browser completely.

Is this a dupe of bug 32335 ?

I can confirm this on Linux nightly 2000091906. I can't get to any authenticated site just as the original reporter wrote. It must be a regression because the login worked some time ago. And I think it definitely isn't a dupe of 32335.

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

Since my bug report is apparently a dupe of this, I'll close mine out and add my comments here: From 53333: --- Mozilla can not log into a passworded website using basic auth, if the site closes the connection between the 401 Authorization required and when Mozilla prompts for a password/tries again. The problem seems limited to Solaris, or perhaps Unixes in general. I've not been able to produce this bug using a Win32 build, but have been able to do so on two different Solaris boxes against two different webservers. http://www.bofh.halifax.ns.ca/mozilla-test/ If you go to the above URL, you'll be prompted for a username and password. Notice that in the console Mozilla will claim to have loaded the document successfully, when it has not. Enter the user/pass (snog/snuh) and notice that Mozilla does nothing. I can cause and remove this effect by adding/removing this line from my Apache httpd.conf: BrowserMatch "Mozilla/5.0" nokeepalive If you put the user/pass in the URL: http://snog:snuh@www.bofh.halifax.ns.ca/mozilla-test/ ...ugh ...it will load fine. --- Might I be so bold as to suggest that this can be confirmed, since there are so many dupes? I can still produce the behavior with Solaris nightly 2000091312. (Eh? That build ID looks wrong... the nightly on the site (file-dated 2000/09/22, which should be newer than the 2000091821 that also had the same problem...)

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

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

Confirmed with 09/22 build on Linux (for some reason the build ID is wrong). Marking confirmed.

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

The URL on this bug shows exactly the problem I have (see bug 53876). The sunsolve URL is a sufficient test case. I cannot use mozilla until this bug is resolved since it prohibits me from using internal web sites. Can someone raise severity for me to blocker/p2?

Adding keywords and blocker severity. Cannot login to aka.mcom.com or bugsplat.

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

John - is this only occuring for Linux?

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

No, it's happening on Mac too. Dogfood because I need to authenticate to a proxy to go to any Web site.

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

(Using Mozilla/5.0 (X11; U; Linux 2.2.17 i686; en-US; m18) Gecko/20000927) I think I am seeing something very similar to this, except that it works for some pages but not others. For local pages that use the ordinary mod_auth apache module with a local password file, it works fine. For local pages using php scripts to authenticate against a database, then it will not work (in exactly the way described in the other comments on this bug) if I enter the protected page by clicking on the URL from another page; but a if I type the URL into the locator/search box then it *does* work as expected. (The same pages work fine with NS 4 and IE5, so it is not simply a bug in our php authentication script.)

Basic auth is very fundamental to browsing, so I'm marking dogfood-plus. If (as suggested) this is really a rare variant, and most sites can get a basic auth, then we'd downgrade this to dogfood-minus, and just go after an rtm fix.

"Rare" in what sense? As I mentioned earlier, I can cause and remove the problem at will by simply causing the HTTP/1.1 connection to close when Mozilla wanted it open, whether via Apache's built-in authentication or via a module. I think this is the same problem with PHP the previous poster mentioned... I get the same thing with mod_perl, which gives an HTTP/1.1 authentication response but closes the connection. I imagine there's a lot of sites that would generate this kind of situation, and for some reason only Win32 so far seems immune.

I need proxy authentication to do any Web browsing at all. So if this bug is dogfood-ed, I'll probably have to give my QA job to someone else until it's fixed, as I'm not going to pay to download Mozilla builds when I know they're going to be useless.

jar: basic auth itself is working fine. There is something specifically wrong at this site (seems like a weird combination of basic auth and redirects) and so I would insist a dogfood minus and would agree for an rtm+

Gagan: have you read this entire bug? Surely you can see that it is NOT working fine for a lot of sites - it is not just one specific site. There are lots of bugs that are a dup of this one. That should tell you that it is for the most part NOT working. Oracle cannot use ns6 until this is fixed, as we have internal web sites using basic auth which don't work in ns6/moz. Show me one site that works, we can show you 10 (maybe 100) that don't. That is not acceptable results for nsbeta3, is it?

On the URL I cited (http://www.bofh.halifax.ns.ca/mozilla-test/), there is nothing special about the site. It is simply "require valid-user" in the server config. No redirects, no scripts, no modules, no plugins. Only a very simple 'BrowserMatch "Mozilla/5.0" nokeepalive' in the server config is a variation from the norm. This would imply that Mozilla silently fails when authenticating via basic auth against any website that is not willing to keep the connection open. Is this really that rare a situation?

All: While I agree this may be more common than my initial interpretation of this bug, the beta3 train is gone. I agree that this bug is definitely a must fix for RTM.

As a temporary workaround, can someone try this pref and see if the problem goes away? pref("network.http.keep-alive", true);

I'm sorry but it doesn't help me.

Does't work for me either. If this fix doesn't make beta3, it will be useless.

I believe that's what this boils down to. Mozilla no longer exists on any of my machines. There's no point in testing if such an obvious, affecting, and discussed bug can be ignored until its too late to do anything about it.

I noticed a strange behaveure of mozilla on linux. (I have to use a authenticating web proxy.) When I try to load a homepage using the proxy, mozilla claims (in the xterm i started it from) that the page is loaded successfully before the authentication dialog box pops up. Actualy quiet long time befor the dialog box pops up. This seams very unlogical to me.

I've noticed some weird behaviur with this too.. with build 2000093006 on Linux basic authentication appears not to work when i try to follow a link to a page protected with basic auth... but if I open a new window to that page (center mouse button) and get prompted with the password the page will frequently load. Then subsequent pages (also protected with basic auth) will load up fine. I can even follow links outside that realm into non-protected areas and then back in. One really strange thing is that links within the same realm but a different top level directory will bring up the username/password dialog and then fail to load the page.. until I call up a seperate browser window and authenticate there as well. The site that i used to test this had authentication handled with mod_perl (seems to work fine with Netscape 3.x, 4.x and MSIE)

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

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

PDT marking [rtm need info] until patch and code reviews are available.

Any chance of this getting into M18? Not everyone is using the ns betas, and the next release after M18 is a *long* time to have to wait for a bug as common as this.

woo hoo! this bug is finally squashed in the latest Linux CVS builds.. Shall I mark FIXED?

Seems to work in Build 2000100506 on Linux x86.

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

gagan, did any fixes for this land yet? (looking at above comments that suggest this is fixed).

I have been looking at this and the only reason this might have been broken for a while was the event out of sync error that dougt recently fixed (part of fix for bug 54371). I am marking this fixed as such.

marked fixed.

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

verified on branch: WinNT 2000100908 Linux 2000100909 Mac 2000100910 need to verify on trunk

Verified Fixed on trunk builds at http://www.bofh.halifax.ns.ca/mozilla-test/ with u:snog p:snuh linux 101808 RedHat 6.2 win32 101804 NT 4 mac 101804 Mac OS9 Setting bug to Verified and removing vtrunk keyword

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

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