On 3/6/06, Boris Zbarsky <[EMAIL PROTECTED]> wrote: > 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.
ok > > 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"... ;) Remember, necko doesn't know about prinicipals. What should a channel implementation do when it wants to redirect? What context does it pass to the secureNewChannel method? > > What about third-party protocol handlers? > > If we keep the CheckLoadURI checks in nsIOService, I think they should be > ok.... Again, what about channels created by third-party protocol handlers? > > 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). What does "deny" and "allow" mean? What question is being asked that these flags answer? > 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... What matters really is what happens before AsyncOpen is called. Normally, a channel is constructed and then modified (nsIUploadChannel.setUploadStream), and then AsyncOpen is called. Once AsyncOpen is called, the configuration of the channel is effectively frozen. Perhaps you really want to intercept AsyncOpen? -Darin _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
