Darin Fisher wrote:
Well, there must be some API somewhere to get the right context
parameter to pass to necko, right?
There ought to be by the time we're done with 1.9, yes. ;)
I guess I was trying to get you to describe that mechanism since
getting the context is just as important as passing it along.
Ah. Well, the mechanism depends on what's going on, basically... if you're
taking data from a web page and loading it somewhere, the context is the
nsIPrincipal of that document or window or whatever node the data came from.
Basically, whatever place people get the URI from for CheckLoadURI right now.
Or I'd hope they're getting one; if they're not it's a bug.
Ignoring the async proxy call case for a second, the complexity of
getting this context parameter and passing it to this API instead of
nsIIOService's version, is no more or less error prone than
remembering to push that context into a thread local store.
It's no more or less error prone when writing the code, perhaps. It's a lot
easier to catch when reviewing or auditing code.
With the new API, you check whether the new API is being used. If not, it's
probably a security bug. If it is, you check where the context is coming from
-- since it needs to be passed in explicitly, this is not so hard.
With the global or thread-local store, you have to figure out whether some
caller somewhere pushed the right thing. It's a _lot_ harder to verify correctness.
Or at least this is how it seems to me....
Also, I think that this context API will require some modifications to
the channel implementations.
I'm not sure it would, actually.
For example, any channel that issues a redirect will need to forward the
context, right?
Actually, I don't think it would. For a redirect, the principal should be that
of the document the channel would have loaded, not of the document that started
the load. We're checking whether the server is allowed to redirect, not whether
the original page is allowed to open the new URI.
If the context is something more complicated than a principal, I'm not as sure
that the answer is "no"... ;)
What about third-party protocol handlers?
If we keep the CheckLoadURI checks in nsIOService, I think they should be ok....
OK.... so perhaps what we need from a necko point-of-view is a way to
construct a channel with additional properties. And, then we can have
that special new channel method call out to a global set of channel
creation observers that can have access to the channel and the
properties.
Hmm. That might work, yes....
OK. I'd been hoping to be able to output a string representing the capability
that needs to be enabled to load the URI in some cases, but I guess I can just
use bits to express the common cases (allow, deny, chrome only, need universal
xpconnect, need universal browser write, need universal browser read)...
hrm... can you take a moment to define what those mean for channels?
for example, an file channel configured to upload data (to write data
to disk) would seem to need universal browser write, whereas a file
channel configured to read data would seem to need universal browser
read. In other words, it doesn't seem to be sufficient to express
those qualities on the singleton nsIProtocolHandler for the file
protocol.
I was thinking I'd go with the worst-case scenario, I think. So a file channel
would require UniversalBrowserWrite or even UniversalXPConnect. Maybe there
really aren't any useful use cases for anything but
UniversalXPConnect/deny/chromeonly/allow (and I'd argue that UniversalXPConnect
and chromeonly should be the same thing).
We have no idea what the channel is configured for because our security check is
"can we load this URI?" I guess if we were doing the check at channel
construction time we could turn it into "can we load this channel?". That would
actually be kinda nice...
-Boris
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
