Add function to call websocket request from JavaScript

[exeldro]

Description

Add function to call websocket request from JavaScript
This will require page permission full access

Motivation and Context

This makes browser source pages not having to setup a websocket connection to call websocket requests.
Other alternative to #439 and #423

How Has This Been Tested?

On windows 11

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

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

[exeldro]

Rebased

[exeldro]

Used better way to include obs-websocket-api.h
Added an error result for when obs-websocket is not loaded

[tytan652]

obs-websocket-api is now correctly included

[RytoEX]

On this, I need some explanation or justification as to why this is needed. @Warchamp7 @WizardCM ?

[steveseguin]

Just my take, RytoEx:

VDO.Ninja and SocialStream.Ninja make use of the browser source API extensively, but it's rather limited relative to the websocket API.

The browser has WebRTC data-channel support, which bypasses firewalls, so users can control their OBS remotely without proxy servers or opening up their firewall.

Rather than trying to enhance the browser source API, or having users try to enable/configure web-sockets, connection states, ports, and security, just having the websocket functionality be made available via an internal API makes life easier.

The permissions are marked as ControlLevel::All:, so it's possible to offer end users who wish to enable it a clear context of what permissions are being enabled, when setting up their browser source.

I've not tested it myself yet, but having to avoid setting up websockets as an end user to obtain the same functionality via browser source integrations would increase adoption of this advanced functionality.

On this, I need some explanation or justification as to why this is needed. @Warchamp7 @WizardCM ?

[Fenrirthviti]

I am still very wary of adding this, as it is currently my understanding this just provides a full websocket connection without any authorization/interaction from an end user, correct?

If not, what is the exact flow for this, as an end-user who is adding a browser source (or browser dock) that utilizes this? Screenshots or documentation on how this will function in practice will be helpful here.

EDIT: As an additional note, the barrier to setting up something like external websockets control is part of the security, where a user has to make a conscious effort to enable it. You remove that barrier, and this is a significant risk.

[exeldro]

The user has to set the browser access to full in the browser source properties, so it is not enabled by default.

My use case is the markdown source plugin. I want to resize the source based on the contents displayed in the browser source. My previous attempts forgetting this working are #439 and #423, but I was advised this is a better way.

[steveseguin]

As exeldro notes,

At the very least currently, a user would need to select FULL ACCESS TO OBS, as a Page Permission, when setting up their OBS Browser source. "Full Access" already gives a remote user control to start/stop/record and change scenes.

(I would not be opposed to additional confirmation windows, prompting a user to the dangers. )

In the case of VDO.Ninja, a user would further have to include &remote, as a URL parameter, however this is specific to VDO.Ninja. Once activated, the remote user (an IRL streamer on mobile, for example), has remote control to change scenes of their OBS Studio.

For example:

Users on my end want much more control over their OBS remotely; layouts, transitions, better scene state access, control over sources.

[Fenrirthviti]

Thanks.

I understand the use case, but I still feel like this isn't the right approach. Right now, even the "full control" option for browser sources is very limited in what it can read or access. Exposing websockets is providing, effectively, unfettered access to almost the entire OBS internal API. We have historically rejected other additions to the JS API for being too permissive/risky, and I feel like this is the most extreme case of that.

I don't know offhand what an alternate proposal here would be. I get that you want to make it easier for users to set up remote control of OBS from a source outside their network, but again, I feel like the barrier to getting that set up is very intentional already. There is no real strong communication to the end user that setting "full control" is that dangerous with this new addition. The stated examples of start/stop stream are fairly benign, not "read and exfiltrate every single thing in OBS" which this would allow.

This likely needs input and guidance from @Warchamp7 before it can proceed, but I'm just going to note I'm against merging this in the current state, and at the very least, this will need a lot more discussion, and should probably be an RFC first.