-
Notifications
You must be signed in to change notification settings - Fork 150
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
Does url match expression in origin with redirect count? takes a URL, not an origin #519
Comments
This is probably going to have to end up using something like "let |url| be the result of calling the [=url parser=] on the [=serialization of an origin|serialization=] of |origin|" to get an actual URL that can be used. |
Yeah, though perhaps we could redo part of CSP whereby the first half of the algorithm or so becomes its own algorithm that we'd pass url's origin and Permissions Policy can invoke directly. How does it actually work for paths today? |
Do you mean paths in Permissions Policy declarations? I believe that in practice, paths have always been dropped from the string, and only the origin is used. (Chromium parses the URL, and then extracts the origin, throwing away the userinfo/path/query/fragment/whatever-else) |
I was thinking more of the expression containing a path. |
I think that's what I meant, too -- in practice, if the expression in the header / attribute contains a path, then we extract the origin, and store that in the allowlist. Permissions-Policy: fullscreen=https://example.com/index.html has exactly the same effect (in Chromium's current implementation, at least) as Permissions-Policy: fullscreen=https://example.com That said, I think that's not what the spec currently does -- by my reading, the spec currently would parse If we want to match the existing behaviour, then we'd need to explicitly clear the path-part from the host-source before storing it. @arichiv, can you double check that that makes sense? |
Hmm, it doesn't really make sense to me that you'd extract an origin from an expression. Perhaps you mean an origin-expression from a url-expression or some such? I can see ignoring/dropping the path though in the expression. |
Sure -- before we had wildcard support, we would parse the string as a URL (assuming it wasn't Now, I believe that we invoke the CSP parser on that string instead, which returns a scheme/host/port/path struct, and we clear the path member before storing it in the allowlist. |
https://w3c.github.io/webappsec-permissions-policy/#allowlists doesn't appear to invoke it correctly. Origins aren't compatible with URLs.
The text was updated successfully, but these errors were encountered: