A couple comments:
1) You could use thread local storage (TLS) for the context parameter,
and implement this today without any new APIs.
2) Why not use nsIProtocolHandler::protocolFlags to convey capability
requirements?
-Darin
On 3/3/06, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
> I've been thinking about the interaction of security and necko recently, and I
> would like to propose two new APIs for necko as follows (details are
> modifiable;
> I'll explain what I'm trying to achieve below):
>
> interface nsISecureIOService : nsIIOService {
> nsIChannel secureNewChannelFromURI(in nsIURI aURI, in nsISupports
> aContext);
> nsIChannel secureNewChannel(in AUTF8String aSpec,
> in string aOriginCharset,
> in nsIURI aBaseURI,
> in nsISupports aContext);
> };
>
> interface nsISecureProtocolHandler : nsIProtocolHandler {
> // Not sure what the best api is here
> };
>
> The first api will solve the problem of callers forgetting to call
> CheckLoadURI.
> The idea is that the IOService will get some other service by contract (like
> it does for channel redirects), or even have some category of services that
> are
> interested, and notify them all that a new channel is being created for some
> URI
> with some context. The security manager can then QI the context to
> nsIPrincipal
> and do a CheckLoadURI check. This way all callers of secureNewChannelFromURI
> are automatically safe as far as CheckLoadURI goes. Note that this does
> require
> that callers have the principal involved, which means that we may need api
> additions to things like nsIWebNavigation too. Or we could keep it as-is and
> require nsIWebNav callers to do their own CheckLoadURI checks, I suppose...
> But
> I'd rather not do that.
>
> I've been toying with having this method also call content policy, since there
> is at least one content policy we have that's actually a security check. That
> would require passing a lot more data to necko, though, so I'm not sure how
> well
> that would work....
>
> The second API is intended to solve the problem of us hardcoding a list of
> schemes in security manager, with all other schemes being allAccess for
> CheckLoadURI purposes. It would be better if we could interrogate the
> protocol
> handlers themselves for what they think about who should be able to load them.
> Most simply, this can be a single function that returns what capability is
> needed to access the protocol (eg UniversalXPConnect, etc). But maybe
> there's a
> better api here?
>
> Thoughts? I'd really rather like to do this for 1.9 if we can...
>
> -Boris
> _______________________________________________
> dev-tech-network mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-network
>
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
