On 3/6/06, Boris Zbarsky <[EMAIL PROTECTED]> wrote: > Darin Fisher wrote: > > 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? > > It should call newChannel (with a comment explaining why) and then notify > redirect observers. Security manager being one of those. That's the setup we > have now and it's ok for this very special case, imo.
Yeah, that works. > >>> 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? > > Ah, hmm... _that_ is a good question. Right now they just have no way of > doing > meaningful security checks. To enable them to we'd need to either pass a > security context for such checks to them or allow them to get it from > somewhere. > I don't have a strong preference on this, I think, if only because I > suspect > this is much rarer than people creating channels in general. I think the > argument that an explicit context makes catching bugs easier still applies, > but.... > > > What does "deny" and "allow" mean? What question is being asked that > > these flags answer? > > "Am I allowed to load this URI (or channel)?" Hmm... ok. When asking such a question, it would be nice to tell the protocol handler what URI or channel is being queried. With just protocol flags, we can only ask questions about all URIs of a given scheme, and not "this" particular URI. Maybe that's okay. > "deny" means "If you're not nsSystemPrincipal, then no" at the moment. I > think > it should mean "If you don't have UniversalXPConnect, then no". In > particular, > imo "deny" should mean "not even if you're from the same scheme, if you don't > have UniversalXPConnect". > > "allow" means "yes, no matter who you are." So, the question being asked is really about restrictions placed on the consumer of the channel. > > What matters really is what happens before AsyncOpen is called. > > That's the hope, yeah.... I'm not sure some channels don't do stuff before > asyncOpen, but you're right that they shouldn't do it. > > > Perhaps you really want to intercept AsyncOpen? > > That would work as well, possibly even better in terms of having complete > information, but asyncOpen doesn't go through a central place like the > IOService. :( Our channels calls nsIIOService::AllowPort from AsyncOpen (see NS_CheckPortSafety). You could extend that hook, I suppose. -Darin _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
