domipoppe said:
Scripters can locally modify the module (same for PW) and make such glitches easily work again.
Like call server messages clientside etc. This stuff needs to be secured and whilst releasing at as OSP it is hard to secure cause everyone can read the full code.
You see it by the NW troll bettygta etc.
You can make some glitches work by modifying client side code (generally things like wall hacks or unlimited distance name labels, which are just revealing things the client knows but hides from the player), but most should be prevented in server code: messages received by the server from a client should be mistrusted wherever possible. For example, the standard PW code for transferring money from a castle money chest has the client side check for the distance to the chest, whether there is enough money in the chest, then sends the player id, chest instance id, and money to transfer; the server side receives those values and does all the checks again and more, so the distance to the chest is checked again, the money in the chest, also whether the player is in the right faction, has keys, or the chest is broken, and then only if all the checks pass on the server is the money actually transferred and the clients updated. You might notice that the same script cf_use_castle_money_chest is run on both the clients and the server, with some code being run on both, and other bits split up: I designed various scripts this way to share code, and they should be labeled at the first line comment whether server, client, or both.
The general principle is that script checks on the client side can be useful to run preparatory code to find things - which can be computationally expensive, avoiding load on the server where possible - and (on clients not modified to remove checks) to prevent idiots spamming buttons to flood the server with impossible request messages; then every client check before requesting something is also rechecked on the server if at all possible. On the server it is not necessary to check again for every cart that is in range of the player to attach, but the nearest cart that was found on the client side and requested to attach with a network message must be within range and pass every other check in server side code before attaching. This way it doesn't generally matter if the module system is public, since players can't affect the important script checks running on the server. Another example is the PW animation scripts on the server are checked to prevent players calling them too often and being annoying, with the server enforcing a cool down period; as opposed to (if I recall correctly, at least in early days) the animation scripts for Viking Conquest multiplayer, which were not even checked whether the right agent id was sent, so people with modified clients could force other player characters to stop and perform a specific animation using malicious request messages.
My guess is that the exploit of dropping money bags with various (non official) money banking scripts is caused by not removing the money from the player on the warband server before sending the transfer request to the external web server and database: if the player tries to deposit money, the gold amount deposited should be checked and then removed immediately, probably storing the subtracted gold amount in a player slot (something like slot_player_unconfirmed_gold_amount_deposited, also a slot_player_time_gold_deposited with the current mission time), then sending the deposit message to the web server, and if the web server replies quickly enough with a successful deposit message, the player slots are cleared and the money remains unmodified, otherwise the server checks players every now and then with unconfirmed deposits a minute or so old, and refunds the undeposited money value to the player with an error message, so player gold isn't lost due to web server disconnections. Maybe if the server receives a deposit confirmation from the web server for a player without the unconfirmed slots set, the money should be subtracted from the player (in case the web server finally confirmed a deposit after the server gave up and refunded). The player should be prevented from making any further deposits or withdrawals while awating confirmation; alternatively you could only subtract the player gold after a web server transfer was confirmed, but try to make all scripts that deal with player gold fail if the player is marked as awaiting a bank transfer confirmation, so players couldn't drop money bags or buy anything until the bank transfer was confirmed to go through (or you could try overdrafts with penalty interest, jail time, or whatever other things real banks do).
Any time a check is run then a message is sent off to make a modification based on that check in another process later on, race conditions could happen; so ideally the checks should happen immediately in the M&B script before the modification is completed, which since the module system interpreter is not multi threaded - to my knowledge - should prevent that type of exploit.
Server messages or scripts run client side on a modified client should not affect the server, just desynchronize what that player sees compared with the server and everyone else: the section for handling events from the server will not run on a server, since it is inside a block starting with neg|multiplayer_is_server; so it should not affect anything if a modified client sends something like server_event_agent_equip_armor. I don't remember testing whether client scripts can run multiplayer_send_x_to_player operations to other clients, but it seems unlikely, and that would just mess up what the other player sees, not the gold, items, combat calculations, etc. stored on the server.
If you are especially paranoid, it would be possible but annoying to maintain two code bases, with one module system that includes all code and is only run on the server, and a different but compatible module system with all server scripts removed, which is built and released to clients: the released module can then only be used to connect to servers, not host another server or check the server scripts for exploits. I thought about it for PW but decided it wasn't worth the bother, since I wanted to allow anybody in the world to host a server, and to eventually release all the code publicly anyway.