269270 - [FIX]Saved capability principal gives wrong baseURI for document.open() documents

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Dennis Foster]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

I work on a web application that's Java servlet/JSP based. The web app accesses 
the clipboard of the browser's machine via JavaScript. In order to enable this, 
our users set "signed.applets.codebase_principal_support" to true 
in "about:config" and restart Firefox. When the JavaScript goes to access the 
clipboard, the user is asked about "enhanced abilities that are UNSAFE" and do 
they want to allow it. If they simply click "Allow", everything works. However, 
if they click "Remember this decision" followed by "Allow", the current access 
works, but if they shut down and restart their FireFox browser, the next access 
to the servlet (and every access from there on) generates 404 errors. The only 
way to make things work again is to shutdown Firefox, remove the "user_pref" 
settings for "capability.principal.codebase.pX.granted" (and the id) 
for "UniversalXPConnect" from the users prefs.js file and restart Firefox. 
After doing this, the user is prompted again about the "UNSAFE" action with 
every JavaScript clipboard access. 

I have duplicated this problem using Firefox 1.0 on both Windows (fully patched 
XP Pro/SP2) and Mac OSX (fully patched 10.3.6 on a PowerMac G5.) The problem 
does NOT occur using Mozilla 1.7 (on either platform), Camino 0.8 (on my Mac) 
or "some" previous builds of Firefox (I'm not sure how far back I have to go to 
see it work with Firefox, I went quite some time between the last build I 
downloaded (that worked) and version 1.0.) 

FYI: 

On Windows, Firefox's about says: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-
US; rv:1.7.5) Gecko/20041107 Firefox/1.0. 

On Mac OSX, Firefox's about says: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-
O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0. 


Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Dennis Foster]

I have verified that this works correctly using "Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/
20040913 Firefox 0.10" on a SuSE 9.2 Linux machine.

Comment 2

[timeless]

can you post a sample application which shows this problem? and does it happen
in mozilla?

Comment 3

[Dennis Foster]

No, I don't have a way to make our web application available outside of our corporate firewall and as of 
yet, I've been unable to duplicate the problem with a generally accessible web site (application.)  I'm 
continuing to try to find one that exhibits the problem.

As I stated in my original bug report, this works fine with Mozilla 1.7 (Windows and Mac) and Camino 
0.8 (Mac.)  And, as my first follow up comment states, it also works fine with a Firefox 1.0 pre-pelease 
on a SuSE 9.2 Linux box.  I'm going to "downgrade" one of my Windows machines to the last Firefox 1.0 
pre-release I have to see if it works using that.

The error has got something to do with how Firefox has changed how user_pref's granting 
"UniversalXPConnect" privileges in the context of a web application is implemented.  Although my users 
get into this  state using the clipboard support from my web application, its got nothing to do with my 
clipboard support code.  If I simply add user_pref's granting "UniversalXPConnect" privileges to the 
address hosting an instance of our web app, that web app is no longer functional (although all others 
that DON'T have "UniversalXPConnect" privileges are.)  Removing these user_pref's lets the affected web 
app run again.

Comment 4

[Mike Connor [:mconnor]]

the only changes that would have been made between PR and final that would
affect this that I can think of are all security fixes.  If you can create a
test app that exhibits the problem, we can look at it then, but without knowing
what code is there its pretty hard to guess at the possible cause.

Comment 5

[Dennis Foster]

I "downgraded" my Firefox installation to "Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/
20040913 Firefox/0.10.1" and this works (i.e., it DOESN'T exhibit the problem.)  This is the most recent 
pre-release of Firefox I have available.  (Note that I allowed this version of Firefox to "patch" itself with 
the security patch when I first started it up.)

Going back to the 1.0 release of Firefox (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) 
Gecko/20041107 Firefox/1.0) causes the problem to return.  Clearly something "broke" regarding 
UniversalXPConnect very late in the game.

I'll continue testing and try to come up with a publicly accessible way to duplicate this.

I take it there's no easy way to review what changed with UniversalXPConnect between the pre-release 
and the 1.0 release.

Comment 6

[timeless]

sorry, by mozilla i meant the current version (grab a nightly), i did and do
read reports before commenting, so the question was meant to determine whether
the trunk was affected (it's not supposed to happen that ff1.0 and mozilla1.7.5
are out of sync, but it is the case, and a change for ff1.0 could conceivably be
on the trunk too).

Comment 7

[Dennis Foster]

Sorry, I didn't mean to imply you didn't read my inital report.  It was kind of wordy and I thought 
perhaps you just missed that point.

I downloaded the nightly build of Mozilla and it works fine (i.e., the issue I reported in Firefox is NOT 
there.)  Just to verify, its "About" says Mozilla 1.8a5 with the following description: "Mozilla/5.0 
(Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041112"

Comment 8

[Dennis Foster]

Ok, a little headway here.  Hopefully I can explain this clearly enough that it may be of some use to 
somebody :-)

I ran a sniffer as to what's going across the wire in both working and failure conditions.  When things 
are working, HTTP packets like the following are sent:

GET /nps/servlet/frameservice?NPService=fw.LaunchService&...more parameters...

When things are NOT working (i.e, when "UniversalXPConnect" is set), the HTTP packets contain the 
following:

GET /frameservice?NPService=fw.LaunchService&....more parameters....

Note that I'm clicking on the SAME link in the web application in both cases, in the first (with "/nps/
servlet/frameservice"), it works, in the later (where it's just "/frameservice") it doesn't.  Somewhere 
along the way, the "UniversalXPConnect" is causing the URL being submitted to be munged.

This ties in well with the 404 we're getting which is "The requested resource (/frameservice) is not 
available." (note the missing "/nps/servlet" in front of "/frameservice".)

Does this help?

Comment 9

[Dennis Foster]

Attachment: Contains HTML files that demonstrate the problem

Steps:
1. Expand the attached zip file into a temporary directory.
2. Bring up Firefox (the shipping version):
3. Goto "about:config".
4. If it's not already set, set "signed.applets.codebase_principal_support" to
"true".
5. Restart Firefox.
6. Open "index.html" from the directory the zip was expanded into in step 1.
7. Hover over the "Click here to test" link.  Note the target URL for the link
that gets displayed in the status bar.
8. Click the "Click here to test" link.  Note that "Success!" is displayed in
the right frame.
9. Click the "Click here to enable UniversalXPConnect..." link in the left
frame.
10. In the dialog, check the "Remember this decision" checkbox and press
"Allow".
11. Note the "You must now restart..." message and press Ok.
12. Restart Firefox.
13. Open the "index.html" file from the directory the zip was expanded into in
step 1 again.
14. Hover over the "Click here to test" link.  Note that the target URL
displayed in the status bar is NOT the same as it was in step 7 above.

*** THIS IS THE FAILURE.  THE URL'S SHOULD BE THE SAME ***

15. Note that if you click the "Click here to test" link, the link doesn't
work.  It's not working because relative URLs don't work in this situation when
UniversalXPConnect has been enabled on the connection.

Comment 10

[Dennis Foster]

Bummer!  Rather than seeing this problem get fixed in Firefox (which it hasn't yet), I now see that the 
bug has "migrated" to Mozilla itself (using version 1.7.5.)

Comment 11

[Daniel Veditz [:dveditz]]

"Firefox:OS Integration"? This is as clearly CAPS as anything.

Comment 12

[Daniel Veditz [:dveditz]]

Thanks for the testcase!

Comment 13

[Daniel Veditz [:dveditz]]

This is a regression from bug 57600, which changed nsHTMLDocument::Open from
using the DocumentURI to using the CodebaseURI off the principal.

Most of the time this is identical because for documents that don't really have
a principal we just make one up containing the full URI so we have something to
compare against. But if a codebase principal was saved then if we encounter
pages from that site we give it the cached principal which has only the "origin"
(scheme+host+port) info.

I bet the results are worse if the saved principal were cert based.

Pincipals really ought to be opaque to everything except the security code. Do
we have more code trying to peek inside like this?

The originally proposed patch doesn't look like it would have this problem. The
trunk patch (which landed only recently) is somewhat different and I haven't
tested it yet. but it looks like it does the same thing.

Comment 14

[Daniel Veditz [:dveditz]]

There are rather a lot of places that could be problems
http://lxr.mozilla.org/mozilla/source/content/base/src/nsContentAreaDragDrop.cpp#571
http://lxr.mozilla.org/mozilla/source/content/base/src/nsFrameLoader.cpp#160
http://lxr.mozilla.org/mozilla/source/content/base/src/nsContentSink.cpp#381
http://lxr.mozilla.org/mozilla/source/content/html/document/src/nsHTMLDocument.cpp#1490
(and other places in nsHTMLDocument.cpp)
http://lxr.mozilla.org/mozilla/source/docshell/base/nsDocShell.cpp#1039
http://lxr.mozilla.org/mozilla/source/dom/src/base/nsGlobalWindow.cpp#4809
http://lxr.mozilla.org/mozilla/source/extensions/transformiix/source/xslt/txMozillaStylesheetCompiler.cpp#586
http://lxr.mozilla.org/mozilla/source/extensions/webservices/schema/src/nsSchemaLoader.cpp#622
http://lxr.mozilla.org/mozilla/source/extensions/webservices/security/src/nsWebScriptsAccess.cpp#254
http://lxr.mozilla.org/mozilla/source/extensions/webservices/soap/src/nsHTTPSOAPTransport.cpp#197
http://lxr.mozilla.org/mozilla/source/extensions/webservices/wsdl/src/nsWSDLLoader.cpp#156
http://lxr.mozilla.org/mozilla/source/extensions/webservices/wsdl/src/nsWSDLLoader.cpp#466
http://lxr.mozilla.org/mozilla/source/extensions/xmlextras/base/src/nsDOMSerializer.cpp#161
http://lxr.mozilla.org/mozilla/source/modules/oji/src/ProxyClassLoader.cpp#122

Comment 15

[Daniel Veditz [:dveditz]]

nsContentAreaDragDrop.cpp: OK
nsFrameLoader: referrer could be wrong (just origin, or blank)
nsContentSink.cpp: OK (origin used to set cookies)
nsHTMLDocument.cpp: mostly OK except for this problem
nsDocShell.cpp: looks appropriate, but ValidateOrigin isn't using true
        document.domain -- is that just a signal for relaxed checking?
nsGlobalWindowImpl.cpp: OK
txMozillaStylesheetCompiler.cpp: looks OK
nsSchemaLoader.cpp::GetResolvedURI: has this same bug
nsWebScriptsAccess.cpp: OK
nsHTTPSOAPTransport.cpp: don't understand the use of the sourceURI sent to the  
        server. Does it have to be the real URI, or is it just a domain check?
        If the former it could be wrong as in this bug
nsWSDLLoader.cpp::GetResolvedURI: wrong as in this bug
nsDOMSerializer.cpp: ok (checkSameOrigin)
ProxyClassLoader.cpp: no idea what the Java factory needs. Probably OK.

Comment 16

[tpew]

What is happening with this bug? It is still a problem and we are forced to do some pretty ugly procedures to work around it.

Comment 17

[Boris Zbarsky [:bzbarsky]]

We're relying on principals having useful URIs in a whole bunch of places now... we really need to fix this.

Comment 18

[Boris Zbarsky [:bzbarsky]]

See for example bug 294689.  I'm just gonna post a patch, I guess.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch that fixes the attached testcase

Should also fix bug 294689

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 245879 [details] [diff] [review]
Patch that fixes the attached testcase

r=dveditz

Comment 21

[Johnny Stenback (:jst)]

Comment on attachment 245879 [details] [diff] [review]
Patch that fixes the attached testcase

sr=jst

Comment 22

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 23

[Samuel Sidler (old account; do not CC)]

v.fixed Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050704 Minefield/3.0pre