Closed
Bug 92175
Opened 23 years ago
Closed 23 years ago
incorrect handling of htaccess-style authentication
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
People
(Reporter: fallous, Assigned: asa)
References
()
Details
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•23 years ago
|
||
> 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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•