The React UI running in a browser can't connect to the backend without
punching a hole for CORS, which isn't done by default. We don't need the
API key to protect from browsers, and anything else running on the
user's machine that can access the backend (that's hosted on only
localhost) already has enough control to do damage without using
Liberation as an attack vector.
https://github.com/dcs-liberation/dcs_liberation
We don't have any sensitive data, but we do access the file system. On
the off chance that some phishing website decides to try to use
Liberation as an attack vector, prevent access to the API by
unauthorized applications. An API key is generated at each program start
and passed to the front end via the QWebChannel.
A possible explanation for the infrequent CTDs we've been seeing since
adding fast forward is that QWebChannel doesn't keep a reference to the
python objects that it passes to js, so if the object is GC'd before the
front end is done with it, it crashes.
We don't really like QWebChannel anyway, so this begins replacing that
with FastAPI.
Rather than polling at 60Hz (which may be faster than the tick rate,
wasting cycles; and also makes synchronization annoying), collect events
during the tick and emit them after (rate limited, pooling events until
it is time for another event to send).
This can be improved by paying attention to the aircraft update list,
which would allow us to avoid updating aircraft that don't have a status
change. To do that we need to be able to quickly lookup a FlightJs
matching a Flight through, and Flight isn't hashable.
We should also be removing dead events and de-duplicating. Currently
each flight has an update for every tick, but only the latest one
matters. Combat update events also don't matter if the same combat is
new in the update.
https://github.com/dcs-liberation/dcs_liberation/issues/1680
