Since we removed the request-headers field from the violation reports in bug 664983, sites no longer have a reliable way of identifying the user that experienced the violation. We should send Cookies and Authorization headers, if they exist in the browser for the site in question, with the report request. I verified with Adam Barth that this is what the WebKit implementation does. This should also fix bug 658979.
Created attachment 553955 [details] [diff] [review] Fix - remove LOAD_ANONYMOUS
Comment on attachment 553955 [details] [diff] [review] Fix - remove LOAD_ANONYMOUS r=dveditz since fixing bug 664983 we found a couple popular sites who were working towards a CSP deployment who now can't tell what the violating content was without knowing the user who had the violation. They were pulling cookies out of the response headers we killed and they still need that information. Firefox 6 is a loss for those folks and they now can't deploy, but we have a chance to take this safe fix and make Firefox 7 usable for them.
Comment on attachment 553955 [details] [diff] [review] Fix - remove LOAD_ANONYMOUS Approved for beta and aurora.
mozilla-central merge: http://hg.mozilla.org/mozilla-central/rev/b354d9b3e9e1
mozilla-aurora merge: http://hg.mozilla.org/releases/mozilla-aurora/rev/a2533f29b2d6 mozilla-beta merge: http://hg.mozilla.org/releases/mozilla-beta/rev/39f898b72ee2
Can anyone please help me with some guidelines or STR I can use to verify this fix? Thank you
(In reply to Ioana Budnar [QA] from comment #6) > Can anyone please help me with some guidelines or STR I can use to verify > this fix? Create a web page that: 1. sends Set-Cookie 2. sends a Content Security Policy with a report-uri 3. contains a policy violation Verify that the report request contains the cookie you set in 1.
qa- based on comment 7. If someone can provide a testcase to test this bug fix please do so.