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
It can be very useful to know which platform you're connecting to in
the case of things like text input modification, where Windows uses
GDI while unix uses FT2.
Like inputs, if a group is ungrouped, the group itself is not removed.
What actually happens is the removal of the last scene item triggers
a destroy, just like with inputs.
This modifies the old signal selection in favor of falling back
to the destroy signal if an object is not explicitly removed.
This commit cleans up a bunch of code in the event handler,
making it much easier to understand (IMO). I feel much better
about how we handle connecting and disconnecting callbacks. Before,
we were actually allowing a bunch of callbacks to stay connected and
get cleaned up. Now, we actually properly disconnect them.
* Implement filter requests
* Fix CreateSourceFilter
* Implement most Filter events
* build against 27.1.3
* Update main.yml
* SourceFilterNameChanged rename
* revert main.yml changes
* rename SourceFilterCreated and revert CI changes
* cleanup
* Base: Various cleanups + fix -Werror
* Base: A few nitpicks/fixes
* requesthandler: Fix CreateSourceFilter
* utils: Fix CreateSourceFilter
Use obs_source_t* instead of OBSSourceAutoRelease to prevent double
release
* requesthandler: Remove filterIndex from CreateSourceFilter
The purpose of sceneItemEnabled in CreateSceneItem is to hide the
scene item while we still hold the scene mutex (guaranteeing the input
will never be shown). Since we don't hold a mutex when creating
filters, there's no reason to do any extra steps.
* requesthandler: Validate input/filter kinds in *DefaultSettings
Co-authored-by: tt2468 <tt2468@gmail.com>
