Closed Bug 1066868 Opened 6 years ago Closed 4 years ago

Find the right requestingPrincipal for content policy call in nsDocShell


(Core :: DOM: Security, defect)

Not set





(Reporter: tanvi, Unassigned)



When callers don't pass in an Owner, we use the referrer to find the loading Principal in nsDocShell.cpp, which doesn't make a whole lot of sense:

We copy this behavior to populate the loadInfo in bug 1038756.

This bug is to to figure out how to get the loading Principal when the Owner isn't set.
bz, olli, what do you guys think is the path forward here?

I feel like docshell is perpetually growing new code paths for triggering navigation and old ones never die.

Should we start by making sure that all code paths at least have a "triggering principal" argument, and then start asserting that it's non-null?
Makes sense, though it can be still difficult to decide in some cases what the triggering principal is. But sure, docshell shouldn't really decide that, but whatever is initiating the load.
I think we might already be there, pretty much... except that chrome script currently has no sane way to say "do a load with this triggering principal".  We should add such a way and work on deprecating the current scriptable nsIWebNavigation.loadURI without a triggering principal or making it clear that it does that load with system as triggering principal.

But yes, the first step is verifying that nsIWebNavigation.loadURI is the only entrypoint that has no triggering principal right now.
See Also: → 1105556
Blocks: 1105556
Tanvi, can we mark this bug as a duplicate of Bug 1181370? Or is that one doing yet something different?
Flags: needinfo?(tanvi)
Closed: 4 years ago
Flags: needinfo?(tanvi)
Resolution: --- → DUPLICATE
Summary: Find the right loadingPrincipal in nsDocShell → Find the right requestingPrincipal for content policy call in nsDocShell
Duplicate of bug: 1181370
You need to log in before you can comment on or make changes to this bug.