Allow WebSocket requests over the network

[WizardCM]

Description

Well this solution ended up being different than I expected.

I had previously prepared WizardCM@4c65eaa which would show a permission request dialog.
However, in my testing today, this dialog does not get triggered for a website attempting to access the local network for WebSockets, at least on CEF 150. Neither OnRequestMediaAccessPermission nor OnShowPermissionPrompt get called.

This is strange, because on a shipping version of Google Chrome, a permission dialog is displayed, and clicking Allow enables the connection. Further digging is required but is not a blocker for this PR.

The flow in CEF works like so

• Microphone/Webcam permissions go through OnRequestMediaAccessPermission
• Most other permissions go through OnShowPermissionPrompt
• Local network WebSocket is tied to https://github.com/chromium/chromium/blob/8408977/services/network/public/cpp/features.cc#L273-L279

Webcam and Microphone seem to continue to work via --enable-media-stream per this documentation, which I have verified is true. This behaviour is unchanged before or after this PR.

With Alloy style, default handling will deny the request. This method will not be called if the --enable-media-stream command-line switch is used to grant all permissions.

Motivation and Context

Retain pre-Chrome-runtime behaviour for all permissions (for now). In this case, the ability for a browser source or dock's webpage to make outgoing WebSocket requests.

Fixes ERR_BLOCKED_BY_LOCAL_NETWORK_ACCESS_CHECKS

We do not want to provide regressions while a better solution is devised.

At the same time, we also don't want to open too many security holes by using broad toggles.

How Has This Been Tested?

Launch with CEF 150 on Windows pointed to https://obs.wesbos.com/

Attempt to log in.

Types of changes

• Tweak (non-breaking change to improve existing functionality)

Checklist:

• I have read the contributing document.
• My code has been run through clang-format.
• My code follows the project's style guidelines
• My code is not on the master branch.
• My code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[Warchamp7]

Have not explicitly tested the change, but the behaviour is desired for now per the PR description.

[seklow]

Follow-up on this PR: it exempts WebSockets, but the other request types from remote HTTPS browser sources to local services will still be blocked on CEF 150.

LocalNetworkAccessChecks is enabled by default in Chromium 150 (services/network/public/cpp/features.cc), and only LocalNetworkAccessChecksWebSockets is disabled here. fetch, XHR, EventSource and other subresources from a public origin to localhost go through the URL loader's local-network-access interceptor. Without a granted permission they fail with ERR_BLOCKED_BY_LOCAL_NETWORK_ACCESS_CHECKS, and the console shows "Permission was denied for this request to access the loopback address space".

This affects remotely hosted overlays that read a local app's HTTP/SSE API on http://localhost:<port>, such as game mods and companion apps. They work on 32.2.2 (CEF 127) but would stop receiving data in 33.0.

Reproduced on Chromium 149, which uses the same network-service path. The page is made public via --ip-address-space-overrides, and the local server allows the origin via CORS:

Setup	EventSource	fetch
same address space	ok	ok
public page, no permission	blocked	blocked
public page, local-network-access granted	ok	ok

I have not reproduced it in an OBS Git build. The analysis is based on master (a162443) plus the WebSocket failure you already hit here. Since no permission callback was reached for WebSockets either, a permission handler alone may not cover it.

Could the "retain pre-Chrome-runtime behaviour" intent be extended to these requests before 33.0? That would mean either disabling LocalNetworkAccessChecks as well, or having the planned permission implementation grant local-network/loopback access to browser sources and docks for fetch, XHR and EventSource, not only WebSockets.