A headless facade that acts as a game host and provides web-based administration. Automation category: Terasology Facade. See https://forum.terasology.org/threads/facadeserver-headless-server-with-web-interface.1906
This pull request contains the code to manage a list of client IDs recognized as server administrators, as described in the first part of the August 13 (week 11) blog post.
Short recap:
Being a server administrators means having write access to the module installer, configuration and savegame list.
When a new server (i.e. empty data directory) is started for the first time, access to admin-restricted resources is public. The reason for this is that when the server is in the idle state (not running any game) it's not possible to connect using the regular game client, which is what triggers the generation of a client identity; it's only possible to connect anonymously using the web client or API.
As soon as a regular client connects, that client becomes the only server administrator. the recommended workflow for setting up a server is to start it, access the web interface and create and start a game, then connect using the game client to restrict the administrative access to yourself.
Using the web interface, an authenticated administrator can add or remove other client IDs from the administrator list by either:
pasting the client ID of the new admin, or
if a game is running (thus there is a 1:1 correspondence between nicknames and client IDs), picking a name from the list of connected players.
If an administrator removes everyone from the list including himself so that the admin list becomes empty again, the access to admin-restricted resources becomes public again.
A clarification about the two methods added to WritableResource:
boolean writeRequiresAuthentication() must return true if the resource is only writable by a non-anonymous player, i.e. it interacts with the in-game entities of the running game and thus a client entity is required to access it. For example to write to ConsoleResource (execute a command) you need a client entity; to write to ModuleInstallerResource (installing modules) you don't, because you are not manipulating in-game entities.
boolean writeIsAdminRestricted() must return true if writing to the resource is restricted to server administrators; it's possible that a resource is restricted to administrator because it modifies server-wide (and not game-local) files or configuration, but isn't restricted to authenticated clients because it doesn't manipulate in-game objects. In this case, when the admin list is empty (i.e. early server setup phase) this resource can be written to by everyone without authentication.
This pull request contains the code to manage a list of client IDs recognized as server administrators, as described in the first part of the August 13 (week 11) blog post.
Short recap:
A clarification about the two methods added to
WritableResource
:boolean writeRequiresAuthentication()
must return true if the resource is only writable by a non-anonymous player, i.e. it interacts with the in-game entities of the running game and thus a client entity is required to access it. For example to write toConsoleResource
(execute a command) you need a client entity; to write toModuleInstallerResource
(installing modules) you don't, because you are not manipulating in-game entities.boolean writeIsAdminRestricted()
must return true if writing to the resource is restricted to server administrators; it's possible that a resource is restricted to administrator because it modifies server-wide (and not game-local) files or configuration, but isn't restricted to authenticated clients because it doesn't manipulate in-game objects. In this case, when the admin list is empty (i.e. early server setup phase) this resource can be written to by everyone without authentication.