General > Developers Corner

How does the ULX ban time work?

<< < (2/2)

JamminR:

--- Quote from: jakej78b on October 31, 2014, 07:39:19 PM ----thought hooking CheckPassword completely overrode the source check for a bad password
-would be more informative to the user that was banned by displaying information about the ban

--- End quote ---
Not sure fully how CheckPassword works, but, yes, Garry may have written to do just that on the server side. Server lua would be running before the player's lua init would of course, so I could see it could basically overwrite.
I agree with your "more information" idea and like it. My only concern would be that of ban spam.
When minges constantly bang against the locked door of a ban, and the server constantly notifies the other players "idiot tried connecting, but is banned" 20-30 times, though annoying, it's not too much info. If using Lua to send reasons/admin who did it, time expired, whatever info, you then add to the server's workload to send to the ban minge.
Not sure how much more, but, just a slight concern I'd wonder about.


--- Quote from: jakej78b on October 31, 2014, 07:39:19 PM ---Source automatically unbans people when their time is up, how does ULib notice that and remove the ban from the table (ULib.bans) and file (data/ulib/bans.txt)?

--- End quote ---
Honestly, after looking, I'm not 100% sure.
ULib has ULib.refreshBans(), but I can't see that we ever call it in ULX.
Nor in my reasonably quick (10 minutes of) searching our repo, I only see that we update the ban table on Ulib.unban and at server startup*. (* = read on, see educated guess)

As for the bans.txt file, hate to admit this, but I'm somewhat lost.
ULX checks the banned users time within the file at server startup (and a ban, if another admin rebans after the first); but I can't find the code relating to when exactly when, if it does, that it's removed when
If that time has past, the ban is not added to the table.
Here's my educated guess - I think we just use attrition.
Temp ban expires mid-game. Player joins. ULib (and ULX) doesn't care. (Remember, we let Source server do the checking).
However, at server startup (and somewhere else I forgot), we re-write the bans.txt file after updating/verifying the time within it.
Those 'temp' bans from bans.txt aren't added to the server's clock, and, I think they're not written back into bans.txt
Either that, or, we just keep the info in bans.txt for historical purposes. I don't have a test server right now to test, but you've gotten my "Wish I had time to install Gmod server to test" juices flowing.

Megiddo/Stickly Man would best know questions to you and could confirm deny any of my theories.
Not sure how much MrPresident has dug into our ban/unban code, but he could probably assist too.
Maybe they'll stop by

Stickly Man!:
Ah, this is likely XGUI's doing- I've added code to create timers every hour for unbanning users. It definitely isn't the best way (or place) to handle it, but I think I added back when XGUI was not a part of standard ULX.

You can see the code here: https://github.com/Nayruden/Ulysses/blob/master/ulx/lua/ulx/xgui/server/sv_bans.lua#L258-268

jakej78b:

--- Quote from: Stickly Man! on November 01, 2014, 03:04:30 PM ---Ah, this is likely XGUI's doing- I've added code to create timers every hour for unbanning users. It definitely isn't the best way (or place) to handle it, but I think I added back when XGUI was not a part of standard ULX.

--- End quote ---

This is a good example of code that should be updated and moved. You'd think unbanning and updating files would be part of ULib, not part of a gui addon for ulx. Wouldn't you say unbanning would be better handled within CheckPassword than it would br in a timer?

I could understand how continually requesting information about the ban could be resource intensive, but you could easily add a flood filter or just leave the information out completely. Even if you still allow source to handle the bans, CheckPassword seems like the best hook for ULib to perform it's table and file updating.

Navigation

[0] Message Index

[*] Previous page

Go to full version