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.
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)?"
"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."
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. :(
-Boris
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
