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
This parameter is a weird one. With the abstraction of requests from
the underlying websocket protocol, there theoretically should be no
need to ignore invalid messages, because the implementation of the
low-level protocol on clients should be solid, with the requests
themselves not being fatal to the session.
As such, I consider this to be feature bloat, with lots of messy code
attributed to it.
We were previously storing config values in the WebSocketServer class
itself, in a weak attempt at modularity. It's better to give up on that
idea and just get it from the Config object itself.
