-
Notifications
You must be signed in to change notification settings - Fork 323
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.
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
Question about tainted origin flag #953
Comments
I think the tainted origin flag is not what you want. You can check request's response tainting to see whether there is a "cross-origin request" in the redirect chain. |
@npm1 if I remember correctly, that captures that if A1 requests A2 and A2 redirects to B, the origin isn't tainted. There's a PR where this is discussed in more detail which can probably be found via blame. |
Found the PR, it's #594. Resource Timing's w3c/resource-timing#214 was supposed to implement similar checks but instead seems to be implementing something different. @yoavweiss it seems the origin only becomes tainted after two cross origin changes, not one. So to match CORS, should https://w3c.github.io/resource-timing/#dfn-timing-allow-check be changed to be less restrictive? |
Yeah, I'm not sure I understand that language. Perhaps it's worth considering merging TAO into Fetch at this point? I don't think it would be all that hard and I think it would put an end to the continued confusion we've been having around this. |
Ok, I will send a PR to add a 'TAO check' in Fetch. Reading the CORS check, it depends on serialization of origin which depends on the tainted origin flag, so we should be using that if the intent is to follow CORS logic. This means the current tainted bool in ResourceTiming is too restrictive, as any cross-origin change would set it. |
I think there's something wrong about the origin tainted flag though in that some of the text suggests it serves a similar purpose to the response tainting flag, which I think is more what you were after. I should straighten that out. |
In step 10 of https://fetch.spec.whatwg.org/#concept-http-redirect-fetch it says
If actualResponse’s location URL’s origin is not same origin with request’s current URL’s origin and request’s origin is not same origin with request’s current URL’s origin, then set request’s tainted origin flag.
I thought that the tainted origin flag is meant to capture whether there are cross origin redirects, is that true? If it is, why is the second check needed? Thanks in advance!
The text was updated successfully, but these errors were encountered: