DevotedMC / BanStick

Player / IP / CIDR / VPN / Shared connection banning with a vengeance. Built for Spigot 1.16.4
http://www.devotedmc.com
BSD 3-Clause "New" or "Revised" License
1 stars 4 forks source link

More complex alt list handling and exclusions #6

Closed Maxopoly closed 5 years ago

Maxopoly commented 6 years ago

First of all, this isn't ready for merging yet, I need to read over it again, add more docu and test it. That being said, it's probably far enough to at least get some thoughts regarding the approach in general.

BanStick seems to have been built around Devoteds single account policy. While it supports more than one account per player, it's handling of player association groups is not powerful enough to deal with the situation that multi accounting servers bring with them.

For example:

Player A plays on IP1, Player B plays on IP1 and IP2, Player C plays on IP2.

It's likely that Player A and C are the same person or at least ip sharing in a way that should be trackable. In the current system they do not have a share though and there is no direct way to find their connection, likely it would go unnoticed forever.

The solution here is to do a recursive lookup through shares to retrieves not only direct shares, but also transitive ones to create alt groups. Basically we're doing graph theory here, players are nodes and shares are edges. To determine alt groups, we are finding the biggest fully connected subgraph containing a given player. An additional config option allows limiting both bans and the account number limitation not only based on shares, but these transitive alt groups.

In an ideal world we'd be done here, but sadly we have to deal with players who use each others account/computer/VPN and get all mixed up in ways they shouldnt be.

Banstick already offers pardoning shares to combat this, but when dealing with situations where we have to assign n different accounts to m players each, pardoned shares are too weak of a concept to solve this problem, especially because new ones may be created in the future, for example when people play in the same house on dynamic ips.

To deal with this, I decided to introduce the concept of exclusions, which are like the opposite of a share. They contain 2 players and specify an edge in the graph, which will be assumed nonexistent when trying to find the alt group subgraph. To create an exclusion, a share between the two players doesnt even have to exist yet though.

Admins are supposed to simply give a list of accounts which make up a real player via command and BanStick will create exclusions to cut all of those accounts out of the alt group they are currently in and create their own little pocket.

As you might have already noticed, the usage and kind of the thought behind it is heavily inspired by MiscLog's approach.

ribagi commented 6 years ago

Any updates on this pull?

ProgrammerDan commented 6 years ago

@Maxopoly New thoughts or ideas on this? Moved on?

Maxopoly commented 6 years ago

This probably works now, at least it did when I messed around with it locally. Follow up to it might be needed, but I probably wont know what to fix until it actually runs on Civclassic prod.

ProgrammerDan commented 6 years ago

from https://www.reddit.com/r/civclassics/comments/8tyaml/changelog_for_6262018/ sounds like this PR is confirmed working? If so, great work man!

Maxopoly commented 6 years ago

It was more like a live test, hold on for a bit before merging until I hear back whether everything works as intended.

ProgrammerDan commented 5 years ago

Any updates on this Max? Good to merge? Has fixes?

Maxopoly commented 5 years ago

Supposedly it's working, so yeah it's probably fine to merge.

ProgrammerDan commented 5 years ago

still looks great. I will try to get to merging it soon.

ProgrammerDan commented 5 years ago

ok to build

DevotedServant commented 5 years ago

Build finished.

ProgrammerDan commented 5 years ago

ok to build

ProgrammerDan commented 5 years ago

build this please

ProgrammerDan commented 5 years ago

test this please