Follow-up Comment #2, bug #18426 (project freeciv):
An idea I had for this: add a Lua function a server operator could edit which
would be able to veto any setting proposed by players. It would be passed the
name and proposed value (as a string) of any setting change, and return a
boolean value whether it's allowed, and return or print a message why not.
Pros:
* Dead easy for us to implement and allows a wide range of policies to be
implemented (compared to us having to have machinery in C to allow operator to
specify min/max for numeric, allowed bits for bitmask settings, sets of
allowed strings for string settings, ... and whatever criteria we provided
would still probably fail to meet someone's needs)
Cons:
* Requires server operators to write code to use this; we can mitigate by
providing examples of common uses (limit maxplayers, limit rulesetdir per
patch #3438).
* Passing string version of value places responsibility on script writer to
validate input, with attendant possibility of mismatch with server's parsing
of input allowing bypassing the validation. We could ameliorate this by
exposing our option parsing functions to the script, and setting things up to
encourage their use.
Might want to expose access level of caller to the script to allow server
operator to implement their own caller access level policy on top of what we
provide.
Probably settings made from the server console or hack-level access should
bypass this, possibly with a warning.
(This ought to run in the same sort of unfettered Lua context as envisaged by
bug #19729, but that's not necessary for initial implementation. However, the
script file should live in the same place as database.lua does today.)
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?18426>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
