Player Police 2: The Design

[Light]

Well, I was setting some of this up as a demonstration of my idea for you and already got an attack from "jas0n". I turned my filters back on to block against attacks like his, but if you'd like .. here's an IP we can start with on the ban list.

186.206.173.35

He has a dynamic IP so it changes pretty frequently, but it's a start.

[Light]

Tested it out, and it appears we have a working copy to at least start out with. If you have some time today, it would be nice to talk to you in-game and see what you think, what it may be missing, etc.

[Lucifer]

On top of that, we could do a real-time check if you think it's a useful idea. It wouldn't really hurt anything, and would possibly give us the ability to have even better features.

Actually, how hard would it be to throw together a request in C++ in the game? libxml2 already gives us the ability to request web pages, does it also allow us to request plain text files? If it does, we might could hack something together that works from the server.

One thing that you've mentioned above that I'm against though is banning through the game (adding to banlist from in-game). At least, it sounded like you were saying that. I think that would be a bad idea because we could either have people spoof what we're using to check, or if we make it something they can't spoof, they could intercept. I think it has to be handled outside of the game. This is only because untrusted people can run the script on their servers, and we don't want trusted people attempting to log in there and give access to the system.

I spent my morning trying to overcome that fundamental flaw, and the truth is, we'll have to have a lot more in place before we can sync banlists like I proposed, so I'm going to agree with you that it should all be handled through a web front-end.

So, yeah! We could have a real-time check with a backup that all goes on inside the script, and requires nothing more than a spawn_script command in their config.

Would the script block the server from continuing to the next round in case there's a timeout trying to reach the webserver?

I thought about the database layout and realized there's a bit still left out, but here goes:

Table "Groups": The list of different types of player police and their userlevels. Some extra meta-information, like a description of the role. Whatever other meta information you can think of that would be useful.

Table "Cops": The actual users. I'm thinking we should have separate fields for username and authority, in case we decide to allow other authorities at some point, but put in a database-level restriction for "forums" for now. If we allow other authorities at some point, we'll create an Authority table and modify this one to link to that one instead of using the authority field. There should also be a sha password stored in this table, but I don't see us using it since we'll be using the armathentication php stuff to authenticate users.

Table "Activity Log": Logs everything a Cop does, including logins and logouts. Bans have to have a reason specified, obviously, and we should have a field for that, and also a field for a more detailed description of the events that led to the ban. Future changes to this table would include adding a screenshots directory to upload screenshots to and listing any screenshots saved as part of the police action.

Table "Reports": This is an open/close table similar to a bug report table. Reports that are open represent ongoing issues that have not been resolved, or that Detectives are working on. This is where Deputies and Sheriffs can file reports on other players so that Detectives can look into it. The creation of a Report also creates a row in the Activity Log.

Table "Banlist": This one's obvious.

As for meeting ingame, my computer is running like crap of late, so it can't run the game right now. IRC? I'm always hanging out there.

[Lucifer]

Ok, thinking about it, add another group to Player Police: Triumvirate. It just occurred to me that we're going to need it, because there will be things that only the Triumvirate can do on the manager website. The use case I considered that led me to believe we need this group is simple: who picks Detectives? Also, who fires/demotes them? One of the answers to that question is "The Evil Triumvirate". So, might as well build in the capability while we're at it.

However, for server security, members of the Triumvirate should be returned as Detectives when the game server is requesting the configs, and the Triumvirate group should not be included at all. That way, game servers can't be compromised by someone pretending to be a Triumvirate, and we don't need any special powers on game servers, only on the Player Police management website.

[Light]

So, since I've already put something together, I'll just try to explain it and we can get together for you to actually see it sometime here if you'd like.

So, there are 4 database tables. (not gonna give actual layout, but a description)

config -> holds the last update time and version for you to compare against
user_level -> has your auth, in-game user level, police user level (will explain later), and the date you got it, date it expires (if it does .. can be null for infinite)
ban -> has an ip, date and time you were banned, the time it expires, and the reason
rank -> just info on your rank - currently an id (rank #) and a name (deputy, etc.)

If someone's ban expires, they will be added to the config with an UNBAN_IP for the next 24 hours. This will make sure they get unbanned, as well as not holding a "forever list". Same goes for user_level, it'll set you back to 15 for the next 24 hours.

The police user level I mentioned above lets you have script commands that users could send from the server. This would allow us to use the script and avoid making people change configs for user levels in order to suit the permissions we want. We could use "/police kill kira" for example.

Every 5 minutes, the script polls my server. If it's up to date, it'll just get this back:

Code: Select all

{"VERSION":1}

Which is the version you sent to the server. Now, if you are outdated (say .. version 0), you would get the configs and whatnot:

Code: Select all

{"VERSION":1,"USER_LEVEL":"USER_LEVEL Kira@lt 1\n","BAN":"BAN_IP 186.206.173.35 525425 DoS Attack\n"}

It will write these out to your specified files and include them.

Code: Select all

// File Names
$file_user_level = "police_user_level.cfg";
$file_ban        = "police_ban.cfg";
$file_override   = "police_override.cfg";

When someone logs in (sadly, it does it on new round as that's when the renamed log goes in), it will check your police user level and set your rank in the script for script commands, along with alerting that you logged in as a police authority and which rank name you are.

What would still need done if this continues is having the web front-end for managing the database, as well as the in-game commands (which would be very quick).

If for some reason my server is unavailable, then you would have the ability to include the files that are currently on the server. I would suggest having them included by your config so my server can be down and even if you reboot your server, it will continue working properly and sync as soon as possible.

This would go in settings_custom.cfg or whatever you feel like ..

Code: Select all

INCLUDE police_user_level.cfg
INCLUDE police_ban.cfg

I think this would about cover your current needs, and we could always add to it?

[Lucifer]

Ahhh, man, that's some out-of-the-box thinking there. It hadn't even occurred to me that doing it this way would let Player Police demote players' userlevels.

The three files I listed need to be included as I listed. That's necessary so that private servers that want to use the system but also want to customize it are able to do so. Putting the INCLUDE in everytime.cfg and one of the other server config files will make sure that even when your server is unavailable, the current cached files will be used.

I would prefer the tables renamed to something resembling the ones I described, and I'd like to see the schema and discuss it. It may sound like painting the bike shed, but it's not. The script should use the information in the database to generate the files, but the database needs to reflect the information in it, not the files it will be used to generate.

Do you have a place you can put a bzr branch where I can check it out and play with it?

Also, does the script block the game server if your server is unavailable? (A fairly easy test to run)

[Light]

Ahhh, man, that's some out-of-the-box thinking there. It hadn't even occurred to me that doing it this way would let Player Police demote players' userlevels.

The three files I listed need to be included as I listed. That's necessary so that private servers that want to use the system but also want to customize it are able to do so. Putting the INCLUDE in everytime.cfg and one of the other server config files will make sure that even when your server is unavailable, the current cached files will be used.

I would prefer the tables renamed to something resembling the ones I described, and I'd like to see the schema and discuss it. It may sound like painting the bike shed, but it's not. The script should use the information in the database to generate the files, but the database needs to reflect the information in it, not the files it will be used to generate.

Do you have a place you can put a bzr branch where I can check it out and play with it?

It's mixed into my site's database, along with using a custom database class for mysqli and whatnot. The naming is also a little different than I mentioned, but wasn't about to start writing out my database layout in public. I'm also not sure why the database table names would matter for anyone but me? The script sees nothing but the arrays I return, unless you were talking about key names. I have a script on my server that puts everything together for you, so in a sense you're using it like an API.

[Lucifer]

It's mixed into my site's database, along with using a custom database class for mysqli and whatnot. The naming is also a little different than I mentioned, but wasn't about to start writing out my database layout in public. I'm also not sure why the database table names would matter for anyone but me? The script sees nothing but the arrays I return, unless you were talking about key names. I have a script on my server that puts everything together for you, so in a sense you're using it like an API.

It's not the names that matter so much as the layout. It looks like what you've described has a table where you put config items, which may be useful, but relying on such a table gives long-term problems when it's time to add new features to the system. The database should not be aware of how armagetron config files are made. The script is responsible for generating the config files. If you really did lay it out that way but simply chose awkward table names, then we're golden, except that I'll ask for more descriptive table names.

Keep in mind that part of my design includes redundancy. That means that I could very well host a mirror of the Player Police manager, so that in the event that yours is down, mine can be used, and vice versa.

Edit: And for the schema, I'd be happy with some table creation SQL output for only the tables involved. You know, you use phpMyAdmin (or whatever that thing is called), output the whole database schema, then delete all the tables that aren't relevant, and post it here, or PM it to me.

[Light]

I'm not gonna get into making it able to be duplicated right now. In reality, we would want replication rather than a separate database functioning on its own, along with the script that generates the files being rewritten so you wouldn't have to include .htaccess files with it. I just don't really feel like splitting things up in my database like that at the moment.

It's not the names that matter so much as the layout. It looks like what you've described has a table where you put config items, which may be useful, but relying on such a table gives long-term problems when it's time to add new features to the system. The database should not be aware of how armagetron config files are made. The script is responsible for generating the config files. If you really did lay it out that way but simply chose awkward table names, then we're golden, except that I'll ask for more descriptive table names.

There are two scripts. One of them are on my webserver that you are querying, and the other is on your server. You query my script, it gives you all of the information, your script would save it and run it. That's about it. The player tracking and police commands would also be done in the game server script, but that's not set up right now.

I figured since it will work even if my server is down, there wasn't really a need for multiple database servers. Maybe I'll change things up a bit once I get caught up with work. I got 4 other servers that need a lot set up right now and a few other projects.

If anything really bad ever were to happen, I could take the server offline and get everything exported off of it to set up on another system or host. So maybe I'll just hold off on the making it able to be cloned until it's necessary.

[Monkey]

I love it when a plan comes together.

[Lucifer]

So, I'm working on the basic Player Police configs that will be distributed with the game.

I've come across an interesting situation. Since we're not going to sync banlists back from servers (security problems, obvious security problems), I considered that maybe Detectives and Sheriffs should have local ban access to deal with immediate problems.

For example: Smeghead is spamming chat. Nobody can talk. On the spot, a Deputy can silence the smeghead, but he keeps leaving and coming back. If a Sheriff is there, he may decide to simply ban Smeghead locally for half an hour, and see if he goes causing problems on other servers. The likelihood is, he won't. But if he does, the Sheriff could go hunt him down and keep banning him, or find a Detective to take the ban to the global level and make it an hour (which requires using the web interface).

I'm going to implement it so that Detectives and Sheriffs can ban locally, but the ban will only be effective for the one server. I think there are a lot of offenders who can be dealt with that way, without having to do a global ban.

Also, a Sheriff can "deputize" someone in this situation, where if the Sheriff is going to go sit on the Master server list and watch for the offending player to reappear on another server, he can op someone that can be trusted to deal with the perp if he comes back while the sheriff's gone. That gives the Sheriff the opportunity to just kick the player and not ban, if it's something as small as spamming chat.

Naturally, the other thread is where we discuss how the Player Police should behave, here we're talking about what capabilities they should have to do what they're supposed to do.

[Light]

I would think a local ban is something you should be able to do, but I would still suggest going more for /police commands and not taking over rank permissions on the servers people host. Also, we could make a command for the configs to update instead of waiting the whole 5 mins, which would then reset the 5 mins. That way if they updated it on the server, they could sync it to the current server immediately. May make more sense for user levels and whatnot than a ban, but still works as an example.

I don't like the idea of requiring configs alongside the police setup. I would think their servers should have any configs they want, allowing any number of ranks with the permissions they want, but be able to implement the police without screwing any of it up. I would really be minimal on any settings changes, if any.

[Lucifer]

Ok, I changed the Player_police.cfg file to eliminate the unnecessary Player_police_base.cfg. Here is what I have:

Code: Select all

# This is the file that creates the Player Police, which are a group of global moderators
# who can moderate any server that subscribes to the Player Police.

# Global IDs have to be accepted for the system to work.
GLOBAL_ID 1

# All default access levels are ignored.  The Player Police use completely different
# access levels.

# Level  Meaning        Details
# 0      Owner          The owner of the server. Commands entered on the
#                       server console are executed with these rights.
#
# 5      Admin          A server administrator. By default, almost as
#                       powerful as the owner himself.
#
# 9      Detective      The highest-ranked of the Player Police.  Using
#                       a web interface, he can globally ban players by
#                       username or IP.  He can also ban players on a server,
#                       but it only takes effect on that server.  Has all
#                       other powers.
#
# 10     Moderator      A server moderator. Is still allowed to use /admin,
#                       but is restricted to player management commands.  Generally,
#                       a Moderator local to the server is equal to a Detective,
#                       but has no powers on other servers.
#
# 14     Sheriff        The middle ranked Player Police.  He has the same powers
#                       on a server as a Detective, but cannot issue global bans.
#
# 17     Deputy         The lowest-ranked Player Police.  He has limited powers
#                       on a server.
#
# 20     Referee        For organized matches, can be elected to use team and
#                       match management commands.
#
# 25     Team Leader    Leader of a team. By default, no admin rights at all.
#
# 30     Team Member    Member of a team. Local team accounts get this level.
#
# 35     Local User     Players with local accounts get this level.
#
# 40     Remote User    Players with remote accounts get this level by default.
#
# 45 Fallen from Grace  Authenticated players who abused default rights given
#                       to them.
# 50     Shunned        Same, only worse :)
#
# 55     Authenticated  Minimal level authenticated players can get.
#
# 100     Program       Unauthenticated players.

# The following directives are documented in settings_authentication.cfg.  These
# are the changes needed to support the Player Police.

ACCESS_LEVEL_ADMIN 5
ACCESS_LEVEL_RTFM 5
ACCESS_LEVEL_OP 25
ACCESS_LEVEL_OP_MAX 5
ACCESS_LEVEL_TEAM 25
ACCESS_LEVEL_PLAY 100
ACCESS_LEVEL_PLAY_SLIDERS 20
ACCESS_LEVEL_PLAY_SLIDING 100
ACCESS_LEVEL_PLAY_INVITED 100
ACCESS_LEVEL_CHAT 100
ACCESS_LEVEL_SHOUT 100
ACCESS_LEVEL_CHAT_TIMEOUT 60
ACCESS_LEVEL_AUTOKICK_IMMUNITY 25
ACCESS_LEVEL_SPY_TEAM 5
ACCESS_LEVEL_SPY_MSG 0
ACCESS_LEVEL_SHUFFLE_UP 30

# Issuing each vote type also requires a certain access level. By
# default (for unchanged behavior relative to previous versions),
# kick and suspend votes are available for everyone.

# The Player Police system may, at any time, decide to change this to
# authenticated users.

ACCESS_LEVEL_VOTE_REMOVE 100
ACCESS_LEVEL_VOTE_KICK 100
ACCESS_LEVEL_VOTE_INCLUDE 5
ACCESS_LEVEL_VOTE_COMMAND 5

ACCESS_LEVEL_VOTE_INCLUDE_EXECUTE 5
ACCESS_LEVEL_VOTE_COMMAND_EXECUTE 5

# This is where the ability to execute commands is set.

ACCESS_LEVEL PLAYER_MESSAGE 5
ACCESS_LEVEL KICK 17
ACCESS_LEVEL BAN 14
ACCESS_LEVEL KICK_TO 17
ACCESS_LEVEL MOVE_TO 17
ACCESS_LEVEL SUSPEND 17
ACCESS_LEVEL UNSUSPEND 17
ACCESS_LEVEL KILL 17
ACCESS_LEVEL SILENCE 17
ACCESS_LEVEL VOICE 17
ACCESS_LEVEL ALLOW_RENAME_PLAYER 17
ACCESS_LEVEL DISALLOW_RENAME_PLAYER 17
ACCESS_LEVEL RENAME 17
ACCESS_LEVEL CONSOLE_MESSAGE 17
ACCESS_LEVEL CENTER_MESSAGE 17

ACCESS_LEVEL ALLOW_TEAM_CHANGE_PLAYER 25
ACCESS_LEVEL DISALLOW_TEAM_CHANGE_PLAYER 25


# This file is downloaded from the player police server.
INCLUDE Player_police_users.cfg

# This file is where you will override player police settings as needed to
# use the system in the way you want to use it.
INCLUDE Player_police_local.cfg

A detective overrules moderators on a server that's under Player Police Protection so that Detectives can deal with renegade moderators.

Other than that, the other ranks basically can do almost everything, with banning shared by Detectives and Sheriffs. The other limitations on their powers will happen on the server that serves up the other config files.

As to Light's post:

I would think a local ban is something you should be able to do, but I would still suggest going more for /police commands and not taking over rank permissions on the servers people host. Also, we could make a command for the configs to update instead of waiting the whole 5 mins, which would then reset the 5 mins. That way if they updated it on the server, they could sync it to the current server immediately. May make more sense for user levels and whatnot than a ban, but still works as an example.

We don't have /police commands, and the idea is to use what's already there so that minimal changes to the game are needed. Since it turns out we have more hooks than I knew about, we can probably do this without requiring code changes on the server.

We can look at making /police commands in 0.5, but I really don't want to add more todo items to the 0.4 release list. That's why we're sticking with what is already there to implement this.

I don't like the idea of requiring configs alongside the police setup. I would think their servers should have any configs they want, allowing any number of ranks with the permissions they want, but be able to implement the police without screwing any of it up. I would really be minimal on any settings changes, if any.

I'm not sure what you mean about configs alongside the police setup. I added the INCLUDE Player_police.cfg line to the end of the armathentication file, so server admins can override any Player Police settings they want. I also realize right now that I wrote the documentation wrong, and need to change it to say "Add this line to server_info.cfg" instead.

The reason I ended up making a lot of changes is because there wasn't room in the defaults to add Player Police, unless I simply made them equal to moderators and such. The other settings aren't touched, or rather, were mapped to the new userlevels I put in there. The default behavior will continue, but server admins will have to change any customizations they've added. I don't see a way around that without having groups implemented (which is basically a named alias for numerical access levels).

Edit: I feel like I should point out that in absolutely no way is any of this set in stone. This is more a rough draft, trying to get stuff together so we can test, and maybe even launch an official server and see how it goes. Nothing's final until it goes through a testing period and we can reach a reasonable consensus.

[Monkey]

Looks pretty good so far. What about the ability for sheriffs and deputies to use VOTES_CANCEL?

[Light]

We can look at making /police commands in 0.5, but I really don't want to add more todo items to the 0.4 release list. That's why we're sticking with what is already there to implement this.

If police servers ran a script, it could easily be a part of that.