CQ passes, feel free to take a look when you have time. Thanks!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Convert ws(s):// to http(s):// for allowlist matching, since the allowlist
// patterns use HTTP schemes.I don't think this is strictly true. We do append HTTPS scheme in situations like DNS where there's no relevant scheme available, but it's probably fine to just leave the ws(s):// scheme as is here. mk...@chromium.org what do you think?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This looks great, thanks! We just need to determine if mapping ws(s) to http(s) is actually necessary or not. Once that's resolved, I can add OWNERS for the relevant directories to take another look.
// Convert ws(s):// to http(s):// for allowlist matching, since the allowlist
// patterns use HTTP schemes.I don't think this is strictly true. We do append HTTPS scheme in situations like DNS where there's no relevant scheme available, but it's probably fine to just leave the ws(s):// scheme as is here. mk...@chromium.org what do you think?
I see there are other parts of the code that convert WebSocket schemes to HTTP for origin checks, so there's precedent for doing this (see line 151 below, even). But I'm also inclined to leave the URL as-is to avoid confusion for developers who are setting WebSocket URLs in the header.
// Convert ws(s):// to http(s):// for allowlist matching, since the allowlist
// patterns use HTTP schemes.Andrew VergeI don't think this is strictly true. We do append HTTPS scheme in situations like DNS where there's no relevant scheme available, but it's probably fine to just leave the ws(s):// scheme as is here. mk...@chromium.org what do you think?
I see there are other parts of the code that convert WebSocket schemes to HTTP for origin checks, so there's precedent for doing this (see line 151 below, even). But I'm also inclined to leave the URL as-is to avoid confusion for developers who are setting WebSocket URLs in the header.
Chatted w/ mkwst offline and it sounds like matching against HTTP has enough alignment with other web features that we also want to do it here. So will resolve this.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Adding kenrb for fido OWNERS
Adding nhiroki for worker OWNERS
// Convert ws(s):// to http(s):// for allowlist matching, since the allowlist
// patterns use HTTP schemes.Andrew VergeI don't think this is strictly true. We do append HTTPS scheme in situations like DNS where there's no relevant scheme available, but it's probably fine to just leave the ws(s):// scheme as is here. mk...@chromium.org what do you think?
Andrew VergeI see there are other parts of the code that convert WebSocket schemes to HTTP for origin checks, so there's precedent for doing this (see line 151 below, even). But I'm also inclined to leave the URL as-is to avoid confusion for developers who are setting WebSocket URLs in the header.
Chatted w/ mkwst offline and it sounds like matching against HTTP has enough alignment with other web features that we also want to do it here. So will resolve this.
oscar...@gmail.com Could you file a Github issue for specification of WebSocket behavior, pointing to this CL? https://github.com/WICG/connection-allowlists/issues
We need to make sure that matching against http instead of ws is captured in the spec.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Convert ws(s):// to http(s):// for allowlist matching, since the allowlist
// patterns use HTTP schemes.Andrew VergeI don't think this is strictly true. We do append HTTPS scheme in situations like DNS where there's no relevant scheme available, but it's probably fine to just leave the ws(s):// scheme as is here. mk...@chromium.org what do you think?
Andrew VergeI see there are other parts of the code that convert WebSocket schemes to HTTP for origin checks, so there's precedent for doing this (see line 151 below, even). But I'm also inclined to leave the URL as-is to avoid confusion for developers who are setting WebSocket URLs in the header.
Andrew VergeChatted w/ mkwst offline and it sounds like matching against HTTP has enough alignment with other web features that we also want to do it here. So will resolve this.
oscar...@gmail.com Could you file a Github issue for specification of WebSocket behavior, pointing to this CL? https://github.com/WICG/connection-allowlists/issues
We need to make sure that matching against http instead of ws is captured in the spec.
Sure thing! Here is the issue: https://github.com/WICG/connection-allowlists/issues/10
// TODO(crbug.com/447954811): Pass network_restrictions_id soOne more request: for the TODOs for workers, can you reference crbug.com/492462310 instead? This is where we'll track remaining implementation work; once this CL merges I will mark the original bug report as fixed.
// Convert ws(s):// to http(s):// for allowlist matching, since the allowlist
// patterns use HTTP schemes.Andrew VergeI don't think this is strictly true. We do append HTTPS scheme in situations like DNS where there's no relevant scheme available, but it's probably fine to just leave the ws(s):// scheme as is here. mk...@chromium.org what do you think?
Andrew VergeI see there are other parts of the code that convert WebSocket schemes to HTTP for origin checks, so there's precedent for doing this (see line 151 below, even). But I'm also inclined to leave the URL as-is to avoid confusion for developers who are setting WebSocket URLs in the header.
Andrew VergeChatted w/ mkwst offline and it sounds like matching against HTTP has enough alignment with other web features that we also want to do it here. So will resolve this.
Tianyi Huoscar...@gmail.com Could you file a Github issue for specification of WebSocket behavior, pointing to this CL? https://github.com/WICG/connection-allowlists/issues
We need to make sure that matching against http instead of ws is captured in the spec.
Sure thing! Here is the issue: https://github.com/WICG/connection-allowlists/issues/10
// TODO(crbug.com/447954811): Pass network_restrictions_id soOne more request: for the TODOs for workers, can you reference crbug.com/492462310 instead? This is where we'll track remaining implementation work; once this CL merges I will mark the original bug report as fixed.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Plumb network_restrictions_id through CreateWebSocketdrive-by nit: Could you please add the prefix "[Connection-Allowlist]" similar to other CLs so it gets the hashtag.
https://chromium-review.googlesource.com/q/hashtag:%22connection-allowlist%22+(status:open%20OR%20status:merged)
drive-by nit: Could you please add the prefix "[Connection-Allowlist]" similar to other CLs so it gets the hashtag.
https://chromium-review.googlesource.com/q/hashtag:%22connection-allowlist%22+(status:open%20OR%20status:merged)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
const std::optional<base::UnguessableToken>& network_restrictions_id)I'm a little concerned that having two std::optionals in the signature might be confusing. Would it be able to pass actual unguessable token always?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Changes in following files LGTM.
content/browser/service_worker/service_worker_host.cc
content/browser/worker_host/dedicated_worker_host.cc
content/browser/worker_host/shared_worker_host.cc
const std::optional<base::UnguessableToken>& network_restrictions_id)I'm a little concerned that having two std::optionals in the signature might be confusing. Would it be able to pass actual unguessable token always?
Not all callers have a network_restrictions_id — the feature is behind an Origin Trial, so most pages won't have one, and non-web callers (FIDO, enclave) have no concept of it. The `/*network_restrictions_id=*/` named parameter comments at each call site should help avoid confusion with `throttling_profile_id`. Happy to hear if you'd prefer a different approach though.
| Code-Review | +1 |
lgtm
const std::optional<base::UnguessableToken>& network_restrictions_id)Tianyi HuI'm a little concerned that having two std::optionals in the signature might be confusing. Would it be able to pass actual unguessable token always?
Not all callers have a network_restrictions_id — the feature is behind an Origin Trial, so most pages won't have one, and non-web callers (FIDO, enclave) have no concept of it. The `/*network_restrictions_id=*/` named parameter comments at each call site should help avoid confusion with `throttling_profile_id`. Happy to hear if you'd prefer a different approach though.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Adding dullweber@ for private_ai OWNERS
Adding ricea@ for content/browser/websockets OWNERS
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
lgtm
ws.addEventListener('open', () => { ws.close(); resolve('open'); });
ws.addEventListener('error', () => resolve('error'));Optional: You can use `addEventListener` if you like, but since no-one else has access to the object anyway, onopen and onerror are fine and I think easier to read:
```suggestion
ws.onopen = () => { ws.close(); resolve('open'); };
ws.onerror = () => resolve('error');
```
SUCCESS,Optional: I think it would be clearer just to pass `"open"` or `"error"` rather than `SUCCESS` or `FAILURE`, but up to you.
| Code-Review | +0 |
| Code-Review | +1 |
ws.addEventListener('open', () => { ws.close(); resolve('open'); });
ws.addEventListener('error', () => resolve('error'));Optional: You can use `addEventListener` if you like, but since no-one else has access to the object anyway, onopen and onerror are fine and I think easier to read:
```suggestion
ws.onopen = () => { ws.close(); resolve('open'); };
ws.onerror = () => resolve('error');
```
Done
Optional: I think it would be clearer just to pass `"open"` or `"error"` rather than `SUCCESS` or `FAILURE`, but up to you.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
averge@ all owners approved, once we have 2 CR+1s again feel free to CQ+2 as I don't have the permission
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Exportable changes to web-platform-tests were detected in this CL and a pull request in the upstream repo has been made: https://github.com/web-platform-tests/wpt/pull/58646.
When this CL lands, the bot will automatically merge the PR on GitHub if the required GitHub checks pass; otherwise, ecosystem-infra@ team will triage the failures and may contact you.
WPT Export docs:
https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md#Automatic-export-process
| Code-Review | +1 |
oscar...@gmail.com looks like network_context_configuration_browsertest.cc needs to be updated with the new network_restrictions_id for websockets, since it's breaking the builds. If you upload a fix I'll review and rerun the CQ.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
oscar...@gmail.com looks like network_context_configuration_browsertest.cc needs to be updated with the new network_restrictions_id for websockets, since it's breaking the builds. If you upload a fix I'll review and rerun the CQ.
Done. Added the missing network_restrictions_id param to network_context_configuration_browsertest.cc. Ready for re-review.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
ri...@chromium.org ba...@chromium.org One more browsertest file was added which needs OWNERS approval, could one of you please take a look? Thanks!
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Commit-Queue | +2 |
[Connection-Allowlist] Plumb network_restrictions_id through CreateWebSocket
WebSocketConnectorImpl::Connect() did not pass the
network_restrictions_id from DocumentAssociatedData to
NetworkContext::CreateWebSocket(), so Connection-Allowlist
restrictions were not enforced on WebSocket connections.
Add network_restrictions_id parameter to the CreateWebSocket
mojom interface and check IsNetworkForNonceAndUrlAllowed() in
WebSocketFactory::CreateWebSocket(). Convert ws(s):// to
http(s):// before matching since allowlist patterns use HTTP
schemes.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The WPT PR for this CL has been merged upstream! https://github.com/web-platform-tests/wpt/pull/58646
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |