LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html - Issue 954233003: Enable SRI only for same origin and CORS content.

Side by Side Diff: LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors.html

Issue 954233003: Enable SRI only for same origin and CORS content. (Closed) Base URL: https://chromium.googlesource.com/chromium/blink.git@master

Patch Set: Rebase on ToT Created 5 years, 9 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« no previous file with comments | « LayoutTests/http/tests/security/resources/cors-style.php ('k') | LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-cors-expected.txt » ('j') | LayoutTests/http/tests/security/subresourceIntegrity/subresource-integrity-script-no-cors.html » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 <!DOCTYPE html>

	2 <head>

	3 </head>

	4 <body>

	5 <script src="/js-test-resources/js-test.js"></script>

	6 <script>

	7 var result = false;

	8 var scriptLoaded = function() {

	9 if (result)

	10 testPassed('Script ran.');

	11 else

	12 testFailed('Script did not run.');

	13 finishJSTest();

	14 };

	15

	16 window.jsTestIsAsync = true;

	17 description("The test passes if the script loads without any console err or messages.");
	Mike West 2015/03/06 03:17:09 Instead of this style, would you mind rewriting th Instead of this style, would you mind rewriting this and the other new tests to use `testharness.js`? Then you can simply assert that the value is set correctly, and can drop the '-expectations.txt' file. jww 2015/03/06 08:24:21 That works in this case, but in the other tests we Show quoted text On 2015/03/06 03:17:09, Mike West wrote: > Instead of this style, would you mind rewriting this and the other new tests to > use `testharness.js`? Then you can simply assert that the value is set > correctly, and can drop the '-expectations.txt' file. That works in this case, but in the other tests we're partially testing the console error messages that appear. Is there any way to test that with testharness.js? Mike West 2015/03/06 09:07:52 If you want to test the error message, then yes, y Show quoted text On 2015/03/06 at 08:24:21, jww wrote: > On 2015/03/06 03:17:09, Mike West wrote: > > Instead of this style, would you mind rewriting this and the other new tests to > > use `testharness.js`? Then you can simply assert that the value is set > > correctly, and can drop the '-expectations.txt' file. > > That works in this case, but in the other tests we're partially testing the console error messages that appear. Is there any way to test that with testharness.js? If you want to test the error message, then yes, you need a test with an -expectation file. We intentionally don't expose the console message's content to JavaScript, as it's sensitive (hashes === content). Those should be written _in addition_ to the testharness.js tests, as the testharness.js tests can be submitted to the W3C, but the console message tests can't. That is, the _interoperable_ parts of the feature (does the thing load?) should be tested in an interoperable way. The Blink-specific bits (console messages) can be tested however you like. :) I'd love to see you rewrite these tests under testharness, and submit them to https://github.com/w3c/web-platform-tests/ to get started on a real test suite for the feature. We can get the Mozilla folks to help out, as these tests should work for everyone. jww 2015/03/09 22:07:45 Yeah, I was hoping there was some test-mode-only A Show quoted text On 2015/03/06 09:07:52, Mike West wrote: > On 2015/03/06 at 08:24:21, jww wrote: > > On 2015/03/06 03:17:09, Mike West wrote: > > > Instead of this style, would you mind rewriting this and the other new tests > to > > > use `testharness.js`? Then you can simply assert that the value is set > > > correctly, and can drop the '-expectations.txt' file. > > > > That works in this case, but in the other tests we're partially testing the > console error messages that appear. Is there any way to test that with > testharness.js? > > If you want to test the error message, then yes, you need a test with an > -expectation file. We intentionally don't expose the console message's content > to JavaScript, as it's sensitive (hashes === content). Yeah, I was hoping there was some test-mode-only API for grabbing console messages, but your comment below clarifies why not. Show quoted text > > Those should be written _in addition_ to the testharness.js tests, as the > testharness.js tests can be submitted to the W3C, but the console message tests > can't. That is, the _interoperable_ parts of the feature (does the thing load?) > should be tested in an interoperable way. The Blink-specific bits (console > messages) can be tested however you like. :) > > I'd love to see you rewrite these tests under testharness, and submit them to > https://github.com/w3c/web-platform-tests/ to get started on a real test suite > for the feature. We can get the Mozilla folks to help out, as these tests should > work for everyone. Sounds great. I'll rewrite with testharness.js, but as I mentioned in the earlier comment, given that the load event/error event part of the spec is still being decided, I'm going to hold off on submitting these tests until that's settled (since they're dependent on the load/error events).
	18 </script>

	19 <script crossorigin="anonymous" integrity="ni:///sha256;eQJgT9bQ7qIxOoZ_I0Oh tpn3EDFGHP2hqHAWogCoOtU=" src="http://localhost:8000/security/resources/cors-scr ipt.php?value=true" onload="scriptLoaded();"></script>

	20 </body>

	21 </html>

OLD	NEW