The security mechanisms aim toward ensuring players follow the game rules which is very important in multi-player games.
Security handlers are introduced to cope with cheat detection and to protect the game from being corrupted.
Therefore the basic protections are :
Some of those security handlers may be by-passed in a trusted environnement (like a non-distributed game) however they also may be usefull to check the handlers architecture consistency.
Another form of security handlers cope with checking that players send the proper orders at the proper time (mainly in a serial game).
The orders to compute sometimes depend on a sequence defined by the game design, like one player and/or one kind of orders at a time.
On player side all commands are assumed to be correctly identified because they only come from the moderator.
Indeed in a distributed environnement the client is supposed to trust the server to which it connects.
On the moderator side unserialized orders must be validated according to the user sending them.
Therefore the moderator should be able to trace the origin of the received orders : players have to identify themselves before sending anything.
Login process e.g. does the io handle the identification ?
UserFactory
Encryption is not specified yet but will probably be handled by serializers (or even by the transport layer ?).
A specific handler called a validator is in charge of the static checks, it will typically be placed right after the serialization input producer.
It may also be used for debugging purpose before a serialization output consumer in order to check that the commands sent should be accepted by the matching input.
A static check is simply a validation that does not require a context to be performed.
Any command has to be validated before being forwarded to the next consumer according to the following specifications :
An order must contain a user parameter identifying who issues the order and the validator must be configured with the user sending the orders once it has been identified and authenticated.
The user issuing a command does not have to be exactly the same as the user sending it : the only requirement is that they are compatible based on game rules.
A given order may be allowed to a group of players, therefore the player sending the order must belong to this group.
Hence the validation is simply ensuring the user sending the order is compatible with the user issuing it e.g. the player belongs to the group.
Order#check()
