1066868 - Find the right requestingPrincipal for content policy call in nsDocShell

Status: RESOLVED DUPLICATE of bug 1181370

(Core :: DOM: Security, defect)

Description

[Tanvi Vyas[:tanvi]]

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:
https://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#9296

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.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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?

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

Tanvi, can we mark this bug as a duplicate of Bug 1181370? Or is that one doing yet something different?