Hi Tanvi, I wasn't very clear about this, but the problem occurs when loading the main HTML document (either into a <browser> element or directly into a normal tab). I guess it's normal that the null principal is used for the main document when a URL is entered into the URL bar. Perhaps I'm getting null for the principal when loading it into my own <browser> since the previous document is about:blank. Anyway, I adapted the code and it seems to work now so this doesn't seem to be an issue.
Thanks for your response, Matt On 14 May 2014, at 07:37, Tanvi Vyas <ta...@mozilla.com> wrote: > Hi Matthew, > > Are you using any other addons that could be calling into nsIContentPolicy? > aRequestPrincipal is optional for non-gecko code, so perhaps another caller > isn't setting it[1]? > > You can also get the principal off the Context[2][3]. Depending on what > information you are trying to gather, this is actually more reliable if you > are looking for the principal of the top level page or iframe that is > attempting to embed a resource. For example, assume https://a.com embeds a > css file from https://b.com. The css file then invokes an image load. When > the content policies are called to see if the image can be loaded, the > aRequestPrincipal is actually https://b.com (the css file that is loading the > image) instead of the page the image is being loaded into (https://a.com). > But the principal associated with the Context in the call to shouldLoad() > will be https://a.com. So, if you are looking for the principal of the page > the resource is being loaded into, you should use the Context instead of the > aRequestPrincipal. If you want the loader of the resource, you should use > aRequestPrincipal. For more on this topic, you can read the discussion > here[4]. > > I am not aware of any changes that might be causing this issue in Firefox 28, > but I was out for a bit so may have missed it. If this is an issue with FF28+ > (and not because of a third party content policy caller), we can do some more > digging. > > ~Tanvi > > [1] > https://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIContentPolicy.idl#234 > [2] > https://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIContentPolicy.idl#234 > [3] Here's some debugging code that might help you along - > http://pastebin.mozilla.org/5010243 > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=909920#c14 > > >> >> -------- Original Message -------- >> Subject: Request principal in nsIContentPolicy implementation >> Date: Mon, 5 May 2014 05:00:00 -0700 (PDT) >> From: Matthew Gertner <matt...@salsitasoft.com> >> Newsgroups: mozilla.dev.platform >> >> I've been using an nsIContentPolicy implementation to restrict access to >> resources that use my protocol handler. Specifically, I only want to >> allow access for requests that come from content under certain >> circumstances. >> >> To check whether the request comes from privileged code, I've been >> comparing aRequestPrincipal in the shouldLoad() method with the system >> principal. As far as I can tell, this has always worked. But now the >> comparison is failing, probably because I upgraded to Firefox 28. >> >> I looked, and for requests from chrome the request principal now seems >> to be null. For the requests from the browser URL bar it is the "null >> principal". Has something changed in Firefox 28 in this respect? What is >> the right way in the shouldLoad() method to check whether the request is >> coming from privileged code or content? >> >> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
