| |||||||
We can ban via IP and KEY from code, when hosted via Dream Daemon. Would it be possible to add the ability to stickyban someone from within code?
| |||||||
Oct 1 2012, 12:12 pm
|
|
Fushimi
 |
Supported.
|
You could make a work-around by saving every different connection made by the account(s).
| |
NNAAAAHH wrote:
You could make a work-around by saving every different connection made by the account(s). That's not an easy work-around in the least. This is why I'm requesting this feature in the first place. | |
I do believe that BYOND it'self captures the IP's used by certain keys (it may capture other things not sure) this feature could easily query the database for that key or IP and ban the user accordingly.
| |
NNAAAAHH wrote:
I agree with the request, I was just offering a work-around. And it's not exactly difficult to do. Having a centralized database would be more effective, someone with the time and resources could easily set something like this up, I have the resources but not the time sadly. | |
A easy way to test this would be to make a hub and 'sticky' ban someone willing and capable and then test uppon that.
And to your reply, I agree. Which is why I support the request. | |
A.T.H.K wrote:
NNAAAAHH wrote: I had actually begun on such a project, but I figure, if BYOND already has the database, why not just query against it? Perhaps also the ability to have a 'client_id' that's unique to each physical player (based off of stickyban?) | |
Querying BYOND's key-association and having BYOND handle a sticky-ban via code for you are quite different things mind, with different consequences in terms of data access and what you can discover about users. The latter I'd be much more comfortable with seeing implemented.
| |
I would definitely love to see this implemented.
| |
In an upcoming version of DD, the ban system has been improved to handle a lookup to our hub-side database correlation system. It won't actually reveal correlations, but if you ban a user and make it "sticky", it will be smart enough to ban related keys (factoring in ips, sids, game history, and other heuristics).
I prefer to have this accessible through DD and not the game because it gives us a consistent, universal approach and the server-operator always has the ability to control his player base. | |
But being able to do this in code would give a lot more power to moderators and administrators of various games, instead of just the host...
We really need the ability to better weed out players, and sometimes using DreamDaemon directly isn't the easiest way to ban a person. That's why we need it via code. | |
Not it mention if you are using Linux...
| |
The DD ban system works fine on linux (and always has) because it uses a text file (hostban.txt). This is essentially just a list of keys that are banned; if a ban is set to sticky, it will block associated keys without writing them to the file. I believe someone has even written a linux tool to better interface with this.
I do see the point about allowing access to mods & admins though. We can probably set something up to access this system through the code. | |
Is there a way to get Linux's DreamDaemon to reload the banfile yet? I remember it being suggested, but I don't remember hearing anything else.
| |
It should automatically recognize when the banfile has been changed. I believe this was in the last version, but I'm not 100% (it may only be in our beta).
| |
I believe you added that quite a few versions ago. You said it would automagically reload every 15 or 30 seconds if a change was made. It was noted in the changelog somewhere.
| |
Tom wrote:
I do see the point about allowing access to mods & admins though. We can probably set something up to access this system through the code. This would be quite useful. I assume just add another flag onto the current system as a specified above if it's a sticky ban? If you feel more power should go to the host, perhaps have a configuration option that allows to the host to set if they want to allow sticky bans via code? | |
I think the power should ultimately reside with the developer, and not the host. It should be up to the developer how (and if) players can be banned. I support this suggestion to allow developers some access to the hub-side database, even if it's limited to managing a server-side ban list and allowing developers to set the "sticky" flag through code.
Giving hosts more control by limiting what a developer can do sounds good on paper until you realize that most hosts aren't even old enough to vote. Another major problem is that it isn't possible for non-hosts (i.e., game moderators) to make use of the same features in banning that the host can because the language just hasn't been changed to accommodate these new DD features. Please stick to providing the developer with the means to override anything you come up with to do out of the box. Making a BYOND game is great and saves a lot of time, but IMHO it isn't worth the effort to anyone if they're just going to be limited by something because someone made an arbitrary decision to do X. | |