You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Worker traffic skips context.route: SharedWorker POSTs and worker WebSockets aren't seen by write guards #1814
Found by the round-4 adversarial review of #1763. The review isn't posted on the PR yet; its findings are recorded here.
Problem. Playwright's context.route doesn't intercept requests made from a SharedWorker. route_web_socket doesn't see WebSockets opened from dedicated or shared workers. So page JavaScript can send an authenticated POST, or open a WebSocket, that no write adapter or wire check sees. Every guard that relies on context.route probably has the same gap, on #1763's browser-teach lane and on main's other teach and wire-check lanes, and that breaks fail-closed.
What has been tried (throwaway probes, not committed):
Network.setBlockedURLs on the page's CDP session doesn't stop worker traffic.
Launching with --disable-shared-workers showed no worker traffic, but the probe page may have stopped at its first SharedWorker call, so this is unconfirmed.
Likely fix. Containment at the browser level, not the page level. Either:
CDP Target.setAutoAttach with flatten, attaching to every worker target and applying Fetch.enable and the network blocks there;
or an enforcing local proxy that every browser context is forced through.
Add real-browser tests covering a SharedWorker POST, a dedicated-worker fetch, and a worker WebSocket. Run them against every lane that claims to hold writes at the network.
Major: later calls of a taught tool block no WebSockets at all.
Major: the click check reads the bounding-box centre, but Playwright clicks the first content quad, so a link that wraps onto two lines gets past the check.
Minor: the key check reads fewer element names than the click check.
Activity