search

ioquake / ioq3

The ioquake3 community effort to continue supporting/developing id's Quake III Arena
https://ioquake3.org/
GNU General Public License v2.0
2.42k stars 529 forks source link

Added built-in http server #558

Open mgerhardy opened 2 years ago

mgerhardy commented 2 years ago

this allows you to get a list of available maps on the server, get the status and download pk3s

pk3 download must get the sv_allowDownload and the download url configured

downloading works when talking to the /pk3 endpoint like this: curl http://localhost:8080/pk3/baseq3/my.pk3

This was the old pull request - https://github.com/ioquake/ioq3/pull/511

g-bougard commented 2 years ago

Hi @mgerhardy

I may have read really too quickly your PR, but can you confirm a point ? It seems to me http requests are processed in the game server process it self. As http requests have nothing to do with the game itself, they should really be handled in a different process: imagine someone start to flood the embedded http server, this could lead to security issues or simply alter the game frame rate itself.

Anyway can you describe all security features you implemented with this built-in http server feature ?

mgerhardy commented 2 years ago

The goal was to get access to the game internal structure without thinking about threading too much. But it should still be possible to put some event queue as the only locked object and use some producer/consumer pattern. Anyway, that was not my goal with this PR - as I've written in the original PR (which I accidentally closed due to silliness) this wasn't meant to be merged.

For security: I did not implement anything in that regard. If I ever put stuff like this online, I would most likely put it behind a reverse proxy like nginx and secure that one. Use the bearer token to ensure that only trusted backends could communicate with this http implementation - and I would most likely convert the output from html to json to be able to continue to work with the data from the game more easily.

And regarding the frame rate, as this is handled in the server tick - yes, an event queue with producer/consumer should be possible in a few lines of code that would more or less decouple the http server frame from the q3 server frame (one could e.g. limit the pulled events to just a little threshold per (q3-)server frame)