I believe it would be bad to enable a network-based WebSocket server
for all OBS users, since obs-websocket usage is very likely less than
a majority of users. A password will still be generated on first run,
so there are no worries about weirdness if a user goes in to enable
the server later on.
I didn't think I'd be able to make remotely usable requests using OBS'
existing projector API, but I'm actually pretty happy with how it
turned out.
Closes#929
Co-authored-by: Brendan Allan <brendonovich@outlook.com>
I generally don't like to echo data provided to obs-websocket in
requests, but since we do that for the request type in base requests,
this particular case seems fair.
Closes#919
**Increments Plugin API Version**
Adds functions:
- `obs_websocket_get_api_version()` - Gets the current obs-websocket
plugin API version
- `obs_websocket_call_request()` - Calls an obs-websocket request via
the plugin API
Adds structs:
- `obs_websocket_request_response`
After discussion in the Discord server, and some internal discussion,
this was deemed a reasonable patch for various security concerns. This
basically controls whether obs-websocket binds to 127.0.0.1 or 0.0.0.0.
I decided to have obs-websocket bind to 127.0.0.1 by default, since
most users appear to be using obs-websocket on the same machines as
their client software. This will be changed if it poses significant
support-related issues.
Further security solutions have been discussed, but are either a heavy
amount of work, or significantly impact client applications' connect
flows.
One idea that I should mention is like a cookie system, where:
- On first connect, obs-websocket asks the user to approve the
connection.
- After authentication, obs-websocket gives the client a token in the
`Identified` message, which the client stores.
- On future connects, the client uses this token, along with the
password, to authenticate without needing user confirmation.
This system will likely be implemented in a future version of
obs-websocket.
Closes#907
