208087 - [FIX]Stylesheet ignored if authentication needed

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Ivar Abrahamsen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030522
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030522

If a page does not need authentication, but a css stylesheet in the page is in a
different location which does, the style sheet gets ignored.

The username and password are prompoted and entered but ignored. The page does
not seem to render untill password entered.

However on refresh the stylesheet is applied, as it no longer neccessary to
prompt for authentication. But people not used to site wont realise that
something is missing.

This seem to apply with Mozilla 1.4b and Apache 2 htpasswd authentication.

I havent tested if this is the same for other filetypes, e.g. js files or
images, but it does seem like a seriuos issue, in one way dataloss, although
only visually.

Reproducible: Always

Steps to Reproduce:
1. open browser and go to a page which does not require authentication, but does
contain a link to a stylesheet which does require authentication.
2. you are prompted for name and password, enter this and press okay.


Actual Results:  
page rendered without applying stylesheet, however refreses does.

Expected Results:  
as it already seem to wait untill password is entered, it should have fetched
the stylesheet and applied as it rendered the page as normal.

Comment 1

[Ivar Abrahamsen]

Would like some comment on this, as I recon it is a significant problem. 

It wont stop your browsing, and if stylesheet is only mild formating, not really
impact you browsing. however if stylesheet applies the more resourcefull
attributes of CSS, like display: none, and other hide/show features then it
would seriously affect the integrety of the sites involved.

Although having a pw protected style sheet makes less sense if the page itself
is not pw protected, however as ive found out in a few cases, it does happen.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I thought we'd fixed this before.  Did it regress?

(I still like the idea of HTTP asserting much earlier than the assertion put in
for bug 199910, which would help us catch things like this when they regress
instead of months later.)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Hmm..  I just tracked back to at least Aug 2002 (when CSSLoader was still using
streamLoader) and we consistently pass in nsnull for the notification callbacks
all along...

What confuses me is that the password _is_ prompted for.  That means that we get
a hold of a notification callbacks object, no?

Comment 4

[Darin Fisher]

yes, from the loadgroup.  it is a nsIRequest with its own notification callbacks
attribute that channels may/should use if there is not one specified on the
channel explicitly.

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK.... so any ideas what the problem is here, Darin?  I assume that the whole
prompting thing is opaque to necko consumers, right?  So once I open a channel
and it has a notification callbacks pointer (eg from the loadgroup) I don't have
to do anything to get things to be happy?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Ivar, any chance of a page that shows the problem?

Comment 7

[Ivar Abrahamsen]

Ive set up http://test.eray.biz/auth.html as an example.
( it is online from about 9am - 1am GMT most days )
Try it first without entering a username & pw. Then enter "test" as username and
pw. Does anyone else see this the same problem?



(Although I cant get mozilla to read the stylesheet at all at the moment...)

This problem does still presist where i first encountered it. but that is my
todo program. and i dont want people to mess around with it!

I however managed to get a similar issue when testing it with Konqueror. It
displayed the page without using the stylesheet and then prompted for the
authentication. It however automaticlly refreshed/reflowed the page and applied
the stylesheet when the authentication was accepted. 

That is the actions I expected Mozilla to do as well, but perhaps not show any
of page if first encountering an stylesheet which needs authentication.

Comment 8

[Boris Zbarsky [:bzbarsky]]

When I load that HTML page, I am not prompted for authentication for the
stylesheet, at all.  Naturally, the sheet is not applied.

If I load the sheet url first (and authenticate myself), the sheet is thereafter
applied when I load the HTML.

So the problem, then, is in fact that there is no prompting for the
username/password on a normal load of the HTML page...  darin, any idea what's
up there?

Comment 9

[Ivar Abrahamsen]

This issue of not beeing prompted at all now, may be bad server configuration by
me. 

However I cant see what I have set up wrong, especially as it is applying the
stylesheet after you have accessed it directly. It works in other browsers and
the logs show the css files is accessed.  

The original stylesheet authentication problem occured with my Tomcat
integration, which may be complicate the issue, but as we have seen there is a
problem with plain Apache files.

Can anyone else replicate the problem? 

Comment 10

[Boris Zbarsky [:bzbarsky]]

This was caused by the patch in bug 199910.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: This fixes http://test.eray.biz/auth.html for me

Comment 12

[Darin Fisher]

Comment on attachment 127254 [details] [diff] [review]
This fixes http://test.eray.biz/auth.html for me

> nsHttpChannel::GetCallback(const nsIID &aIID, void **aResult)
> {
>+    NS_PRECONDITION(aResult, "Invalid argument in GetCallback!");

at one point in time, someone (not sure who) told me that
NS_PRECONDITION is not to be used anymore... maybe that was
just someone being lame.


>     *aResult = nsnull;
>+    nsresult rv = NS_ERROR_NO_INTERFACE;
>+    if (mCallbacks) {
>+        rv = mCallbacks->GetInterface(aIID, aResult);
>+    }

nit: please keep bracket style consistent.  i.e., drop the brackets
if not needed.	also, seems like it would be better to not assign
to |rv| twice.	do this instead:

    nsresult rv;
    if (mCallbacks)
	rv = mCallbacks->GetInterface(aIID, aResult);
    else
	rv = NS_ERROR_NO_INTERFACE;

there's also no reason to preinitialize |*aResult| since this
function returns a failure code when it cannot get the requested
callback interface (all callers check |rv|).

r=darin with those changes.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: address those comments

Comment 14

[Boris Zbarsky [:bzbarsky]]

Checked in for 1.5a.