Anna Nachesa wrote:
In my case, it boils down to the following: there are some resources on the
client side (either in the form of file://foo.html or in the form of
chrome://bar.xul) which have links to some custom protocol (let's say
xxx://whatever). The protocol handler for xxx is a part of the application,
and it is implementing nsIProtocolHandler interface. The following flags are
set: URI_NORELATIVE | URI_NOAUTH | URI_LOADABLE_BY_ANYONE.
The problem: in the case of file://foo.html it is possible to have links to
this protocol (nsScriptSecurityManager->CheckLoadURIWithPrincipal called
from nsContentUtils->TriggerLink returns OK). But in the case of
chrome://bar.xul the same method called (with aFlags=0) from
nsFrameLoader->CheckURILoad returns false and produces the following output:
Security Error: Content at xxx://whatever may not load or link to
chrome://bar.xul.
Right. You can't link to chrome:// in general. This was always the
case. There were some cases where chrome:// resources could be used in
<img> and the like; the change here was to only allow this if
contentaccessible=yes.
It sounds like you're using <iframe src="chrome://bar.xul"> or some
such? That wasn't allowed in Gecko 1.7, as I recall...
I have done some debugging and I saw that the reason for this error is the
special treatment which chrome scheme gets in CheckLoadURIWithPrincipal. It
appears that, if chrome scheme is the target and custom scheme is the
source, then either the nsIScriptSecurityManager::ALLOW_CHROME flag should
have been set by the CheckLoadURIWithPrincipal caller (nsFrameLoader doesn't
set it) or my protocol should have the flag URI_IS_UI_RESOURCE set
Correct. In Gecko 1.7, you could only load chrome:// if your page was
chrome:// or resource://, so we've actually made the setup a bit more
permissive for extension protocols. I have no idea how your code worked
with Gecko 1.7. How did it?
(but then the links from file://foo.html will be rejected as I've learned
already)
That's correct. If file:// could load your stuff and your stuff could
load chrome:// that causes potential security escalations for file://.
So it's not allowed.
I really don't look much forward to tinkering with
nsIScriptSecurityManager::CheckLoadURIWithPrincipal method and force it to
accept our custom scheme, I would rather not change the code which belongs
to mozilla project. Can I change something on my side, then?
Yes. You can change things so that you're not loading chrome:// from
web-accessible content, or so that the content you're loading chrome://
from is not accessible to everyone... I can't speak to what this means
in terms of the design of your protocol setup (maybe you need two
different protocols?)
-Boris
_______________________________________________
dev-embedding mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-embedding
