Bug 1407056: Part 1 - Provide more consistent principal/origin URL to content policies. r=bz,ckerschb

We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.

Our existing content policy implementations which require or expect a loading
principal currently retrieve it from the context node. Since no current
callers require the principal to be the loading principal, and some already
expect it to be the triggering principal (which there's currently no other way
to retrieve), I chose to pass the triggering principal whenever possible, but
use the loading principal to determine the origin URL.

As a follow-up, I'd like to change the nsIContentPolicy interface to
explicitly receive loading and triggering principals, or possibly just
LoadInfo instances, rather than poorly-defined request
origin/principal/context args. But since that may cause trouble for
comm-central, I'd rather not do it as part of this bug.

MozReview-Commit-ID: LqD9GxdzMte
This commit is contained in:
Kris Maglione
2017-10-12 15:43:55 -07:00
parent dc7f55bc85
commit 7b017c97d6
18 changed files with 98 additions and 58 deletions

View File

@@ -10011,6 +10011,9 @@ nsDocShell::InternalLoad(nsIURI* aURI,
int16_t shouldLoad = nsIContentPolicy::ACCEPT;
rv = NS_CheckContentLoadPolicy(contentType,
aURI,
// This is a top-level load, so the loading
// principal is null.
nullptr,
aTriggeringPrincipal,
requestingContext,
EmptyCString(), // mime guess