Closed Bug 53182 Opened 24 years ago Closed 24 years ago

login via basic auth does not work

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: god, Assigned: gagan)

References

(
URL
)

Details

(Whiteboard: [dogfood-][rtm need info]) 

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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
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...
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
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. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Severity: normal → blocker
Keywords: dogfood, nsbeta3
*** 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.
OS: Linux → All
Hardware: PC → All
*** 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.
Keywords: rtm
Whiteboard: [dogfood+]
"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+
Whiteboard: [dogfood+] → [dogfood-][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.
Whiteboard: [dogfood-][rtm+] → [dogfood-][rtm need info]
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.
Blocks: 53195
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.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → 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
Keywords: vtrunk
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
Status: RESOLVED → VERIFIED
Keywords: vtrunk
*** Bug 55828 has been marked as a duplicate of this bug. ***
*** Bug 54066 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.