Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add TAO check #955

Merged
merged 9 commits into from Dec 4, 2019
Merged

Add TAO check #955

Changes from 1 commit
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
5ebf978
Add TAO check
npm1 Oct 29, 2019
9f129a5
Feedback
npm1 Oct 30, 2019
168ca7e
Add flag to response, fixes
npm1 Oct 30, 2019
52e8011
Non-normative
npm1 Oct 30, 2019
c0e715c
More feedback
npm1 Oct 31, 2019
fb5c95a
Update fetch.bs
npm1 Nov 5, 2019
0d21b7e
Rename flag
npm1 Nov 7, 2019
9ff20f4
Nits: type mismatches, wrapping
annevk Dec 3, 2019
648f46e
nits
annevk Dec 3, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
13 changes: 7 additions & 6 deletions fetch.bs
View file
Open in desktop
Expand Up @@ -3542,6 +3542,8 @@ with a <i>CORS flag</i> and <i>recursive flag</i>, run these steps:
<!-- If you are ever tempted to move this around, carefully consider responses from about URLs,
blob URLs, service workers, HTTP cache, HTTP network, etc. -->

<li><p>If <var>request</var>'s <a for=request>timing allow failed flag</a> is set, then set <var>internalResponse</var>'s <a for=response>timing allow failed flag</a>.

<li><p><a href=https://w3c.github.io/webappsec-csp/#set-response-csp-list>Set <var>internalResponse</var>'s CSP list</a>.
[[!CSP]]

Expand Down Expand Up @@ -3910,8 +3912,7 @@ optional <i>CORS flag</i> and <i>CORS-preflight flag</i>, run these steps:
or <a for=/>responses</a> from a service worker for that matter, it is applied here.

<li><p>If the <a>TAO check</a> for <var>request</var> and <var>response</var> returns failure,
then set <var>request</var>'s <a for=request>timing allow failed flag</a> and set
<var>response</var>'s <a for=response>timing allow failed flag</a>.
then set <var>request</var>'s <a for=request>timing allow failed flag</a>.
</ol>

<li>
Expand Down Expand Up @@ -5106,16 +5107,16 @@ agent's <a>CORS-preflight cache</a> for which there is a <a>cache entry match</a
<var>response</var>'s <a for=response>location URL</a>'s <a for=url>origin</a> is
<a>same origin</a> with <var>request</var>'s <a for=request>origin</a>, then return success.
annevk marked this conversation as resolved.
Show resolved Hide resolved

<li><p>Let <var>serializedOrigin</var> be <var>request</var>'s <a for=request>origin</a>,
<a lt="ASCII serialization of an origin">serialized</a> and <a>isomorphic encoded</a>.

<li><p>Let <var>values</var> be the result of
<a for="header list">getting, decoding, and splitting</a>
`<code>Timing-Allow-Origin</code></a>` from <var>response</var>'s <a for=response>header list</a>.

<li><p>If <var>values</var> contains `<code>*</code>`, then return success.

<li><p>Otherwise, if <var>values</var> contains <var>serializedOrigin</var>, then return success.
<li><p>Let <var>serializedOrigin</var> be the result of <a>serializing a request origin</a> with
<var>request</var>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a test for this scenario and browser bugs given that it sounded liked this was not yet how browsers behaved?

How are we going to integrate this with the resource timing specification?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a test for this scenario and browser bugs given that it sounded liked this was not yet how browsers behaved?

I'll modify https://github.com/web-platform-tests/wpt/blob/master/resource-timing/crossorigin-sandwich-TAO.sub.html because it should no longer pass the TAO check with this change. And will also add a crossorigin sandwich which uses '*' in the header to ensure that it still passes. I imagine browser bugs should be filed once the spec change has landed?

How are we going to integrate this with the resource timing specification?

We'll replace the timing allow check algorithm with a query into the response's flag.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They can be filed now (having a brief heads up window is nice), and the test change can be created as well. Ideally we also have a PR ready for Resource Timing. That way we can land it all together and know that it integrates well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/web-platform-tests/wpt/blob/master/resource-timing/crossorigin-sandwich-TAO.sub.html
https://bugs.chromium.org/p/chromium/issues/detail?id=1022816
https://bugzilla.mozilla.org/show_bug.cgi?id=1597808
https://bugs.webkit.org/show_bug.cgi?id=204375

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also w3c/resource-timing#218 (yes, still hand-wavy because what is a resource, but need to fix the use of 'resource' throughout in order to solve that problem).


<li><p>If <var>values</var> contains <var>serializedOrigin</var>, then return success.

<li><p>Otherwise, return failure.
</ol>
Expand Down