21537 - Basic authentication not passed through framesets

Status: VERIFIED WORKSFORME

(SeaMonkey :: Passwords & Permissions, defect, P3)

Description

[Seb]

Version: M11, WinNT SP4, x86

If you basic authenticate at the root level of a site
e.g. http://bla.com/frameset.html
Then the authentication is not passed to the pages contained within this
frameset which are at a lower level in the same site
e.g. http://bla.com/dir/page.html

I left the database key for remembering my password blank - don't know if that
makes a difference?

I have even tried:
http://user:[e-mail]/frameset.html
and this again only passes authenication to the frameset page not the pages it
contains.

Comment 1

[Paul MacQuiddy]

this looks like a necko issue, not single-signon, assigning to valeski

Comment 2

[Stephen P. Morse]

Paulmac beat me to it -- it's definitely not related to the password cache but
rather to the authorization mechanism itself.  I was just about to assign it to
Judson.

Judson will probably need an actual url that fails in order to reproduce the
problem.  Can the reporter please provide one.

Comment 3

[Seb]

Sorry, no URL - it's an IP protected development site.  I think I have
pin-pointed the bug though:

Only if an Error 401 is sent to the browser does it respond by sending the Basic
Auth.  So if you force the Basic Auth (i.e. send an error 401) in one page only,
Basic Auth is not then automatically sent to all pages at the same or deeper
directory level in the website.

I have found that http://user:[e-mail]/test.html
does not send Basic Auth unless the page test.html returns Error 401 first.

This is not normal behaviour for any browser I have come across.

Comment 4

[Paul MacQuiddy]

In general, username:password authentication in the URL's working for me, both
for ftp and http. Are you seeing a problem with the username:password being
stripped out and forgotten?

Comment 5

[Seb]

The way in which most web servers work will not show up this bug.  Most web
servers when not receiving the correct authorization for a restricted page will
send an Error 401 which then prompts the browser to pop-up the basic auth box.
However after this authenitcation has been required once, all browsers except
for mozilla then automatically send basic auth to all pages at the same or
deeper level within the website.

Mozilla seems to only send basic auth after it has received an error 401 for a
page, so if you have a site which sends a different page depending on whether
basic auth is passed, but does not automatically force auth (by sending 401) on
every page then the bug is apparent.

Try these URLs on Netscape, IE & Mozilla:

http://test:[e-mail]/watchlists.html
(frameset forces auth, so auth is passed by mozilla, but frame:
http://test:[e-mail]/en/watchlists/main.html
doesn't force authenication, but displays different content depending on whether
auth is passed or not)

Hope these URL illustrate the problen.

Comment 6

[Stephen P. Morse]

I'm a little confused.  Using 4.71, I tried the url mentioned above, namely:

   http://test:[e-mail]/watchlists.html

and did not get an authentication dialog.  From what you just said, I thought
that this would present the dialog.  Am I misunderstanding you?

Also, don't we need to know the username/password to test out a url that
exhibits the problem?

Comment 7

[Seb]

Yes the username and password is built into the link!

Try:
http://informer.comdirect.co.uk/watchlists.html
user: test
pass: test

Comment 8

[Judson Valeski]

I am unable to reproduce this using the given URL. providing test:test works
just fine for me. I see the entire page and am not asked for more auth info.

Comment 9

[Seb]

No it doesn't work!!!

Try this link in any browser, then try it in Mozilla.  The page is different
because Mozilla is not passing the authenication to the server.

http://test:[e-mail]/en/watchlists/main.html

Comment 10

[leger]

Clearing WORKSFORME resolution due to reopen.

Comment 11

[Judson Valeski]

what build are you using? 4.7 and mozilla show the same page for me. tever, are
you able to repro?

Comment 12

[Seb]

I am using Mozilla win32-M11
For other browsers I have tried Netscape 4.61 and IE 5.01

I have emailed you directly some screen shots of the following link:
http://test:[e-mail]/watchlists.html

Comment 13

[Judson Valeski]

Using my debug build this works fine.

Comment 14

[Seb]

In release M11 there is definitely a problem.  Since I am unable to get M12 to
start without crashing I will have to wait for the next release to check whether
this problem now no longer exists.

Comment 15

[Eli Goldberg]

Bulk move to Single Signon component, which has subsumed Password Cache.

Comment 16

[Tom Everingham]

can't repro this

verified WORKSFORME