92175 - incorrect handling of htaccess-style authentication

Status: VERIFIED DUPLICATE of bug 62108

(SeaMonkey :: General, defect)

Description

[fallous]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.2) Gecko/20010706
BuildID:    20010706

if you're on site www.foo.com/member/ and member is protected with .htaccess,
calling an image from www.feh.com/member/images/ fails even when the .htaccess
is the same as foo.com/member/.  This is an issue since the contents of both
sites may be the same, the only difference being that foo.com is a virtualhost
for feh.com.
Behavior is specific to Netscape6 and Mozilla, Internet Explorer and prior
versions of Netscape handle correctly.
I suspect mozilla sees a different domain and does not attempt to use the auth
info it submitted to the original domain, but unfortunately it does not ask for
new auth info when trying to access the images from the other domain.  Instead
it simply fails to load the images.

Reproducible: Always
Steps to Reproduce:
1.hit domain with .htaccess protected dir
2.have page within dir call image from different dom but using same .htaccess
info as first dom
3.when image loading fails, type new dom url in and auth
4. return to old dom and images will now load correctly

Actual Results:  images failed to load, and no re-auth dialog was offered. 
after manually accessing second dom and auth'ing, return to original dom and
images load correctly.

Expected Results:  should have attempted to try auth info from original dom on
second dom since second dom was referenced by first.  If not "correct" according
to standards, then browser should at least ask for auth on second dom instead of
failing without dialog

Comment 1

[Boris Zbarsky [:bzbarsky]]

> If not "correct" according to standards

Not only is it not correct, it's a security hole... between sending that data
and a referrer header, that gives out hte username, password, and site to use
them on

> then browser should at least ask for auth on second dom instead of failing
without dialog

So it should.  That's bug 62108.



*** This bug has been marked as a duplicate of 62108 ***

Comment 2

[timeless]

.