The allowedUrlHosts headless configuration parameter only adds AccessKey entries to the temporarilyAllowed hosts list with an HTTP and Websockets scope. As a result, Sending/Receiving OSC messages using the respective components can not be performed by a headless host.
I originally found this issue while looking through decompiled code, and confirmed it in-game too. The code in question lies within the AllowHosts method under FrooxEngine.StandaloneFrooxEngineRunner, which is called by the Headless client and passed the list of hosts from the configuration file. The following code snippet was decompiled using ILSpy:
public async Task AllowHosts(List<string> hosts)
{
await Engine.GlobalCoroutineManager.StartTask(async delegate
{
await default(NextUpdate);
foreach (string host in hosts)
{
string _host = host.Trim().ToLower();
int _port = 80;
if (Uri.TryCreate(_host, UriKind.Absolute, out var url) && !string.IsNullOrEmpty(url.Host))
{
_host = url.Host;
_port = url.Port;
}
else
{
string[] segments = _host.Split(':');
_host = segments[0];
if (segments.Length > 1 && int.TryParse(segments[1], out var port))
{
_port = port;
}
}
UniLog.Log("Allowing host: " + _host + ", Port: " + _port);
Engine.Security.TemporarilyAllowHTTP(_host);
Engine.Security.TemporarilyAllowWebsocket(_host, _port);
}
});
}
Note how the last two lines only add temporary AccessKey entries with the scopes of HTTP and Websocket, but not OSC_Sender or OSC_Receiver. This could be addressed by adding accompanying methods for OSC scopes, or replacing the calls with a method that adds a temporarily allowed host with the Everything scope.
Start the headless client on the same machine with the an entry of "127.0.0.1:9001" (or whatever port Protokol is listening on) to the allowedUrlHosts array.
Join the headless, create an empty object and attach an OSC_Sender component, set the HandlingUser to the headless host user, and set the URL to "osc://127.0.0.1:9001"
Attach an OSC_Value component and set the Handler to the OSC_Sender. Give it any path and value.
Observe the "IsSending" field never becomes true on the OSC_Sender component, nor does Protokol log any OSC messages when the OSC_Value is changed.
Expected behavior
With an entry in the allowedUrlHosts configuration option, a headless client should be able to send and receive OSC messages just like it can with HTTP or Websockets.
On a side note (that is probably worth its own feature request issue), it would be nice if allowed hosts could be configured with specific scopes instead of defaulting to everything. The decompiled method above already shows that the entries are being casted into URI's so the host and (default) port can be determined easily, so why not use the URI protocol to determine the scope?
Describe the bug?
The
allowedUrlHosts
headless configuration parameter only adds AccessKey entries to the temporarilyAllowed hosts list with an HTTP and Websockets scope. As a result, Sending/Receiving OSC messages using the respective components can not be performed by a headless host.I originally found this issue while looking through decompiled code, and confirmed it in-game too. The code in question lies within the
AllowHosts
method underFrooxEngine.StandaloneFrooxEngineRunner
, which is called by the Headless client and passed the list of hosts from the configuration file. The following code snippet was decompiled using ILSpy:Note how the last two lines only add temporary AccessKey entries with the scopes of HTTP and Websocket, but not OSC_Sender or OSC_Receiver. This could be addressed by adding accompanying methods for OSC scopes, or replacing the calls with a method that adds a temporarily allowed host with the Everything scope.
To Reproduce
Expected behavior
With an entry in the allowedUrlHosts configuration option, a headless client should be able to send and receive OSC messages just like it can with HTTP or Websockets.
Screenshots
Headless config file:
In-game OSC components:
Protokol:
Resonite Version Number
Beta 2024.5.29.130
What Platforms does this occur on?
Windows, Linux
What headset if any do you use?
No response
Log Files
Headless log: DJ-DESKTOP - 2024.5.29.130 - 2024-05-29 19_14_58.log Client log: DJ-DESKTOP - 2024.5.29.130 - 2024-05-29 19_14_47.log
Additional Context
On a side note (that is probably worth its own feature request issue), it would be nice if allowed hosts could be configured with specific scopes instead of defaulting to everything. The decompiled method above already shows that the entries are being casted into URI's so the host and (default) port can be determined easily, so why not use the URI protocol to determine the scope?
Reporters
No response