PlayAuthed is after the password hook, and is the place where you want to be checking your bans. You can gatekeeper.DropClient(pl:UserID(), "message") any time, assuming you know the player isn't going to be referenced the rest of the frame.
Thanks for this.
This is a server site module and must be run server site.
init.lua is a server site run
cl_init.lua is a client site run
Would it be possible for the the PlayerPasswordAuth hook to also have userid as an argument?
Currently I have to check my database every time a player joins, then if the callback from tmysql returns a steamid that is currently connected the server will ban the ip to drop him from the server.
I would much rather just use the gatekeeper.Drop() function than banning their IP so they leave the server, I can't use kickid on their steamid at this point because according to the command their steamid does not exist yet. I do not wish to have banned clients getting any further into the connection progress because then they can run commands on the server and I don't want that, they are banned they shouldn't be able to do anything to the server from an in-game level.
I've added gatekeeper.GetUserByAddress, I can't find an IClient or userid on the stack, so you have to use the address passed to PlayerPasswordAuth.
You should be aware that not returning immediately allows an attacker to run commands anyway, so you need to decide in the callback whether or not you want to kick them. The solution would be to pre-load the banlist on map load.
Yea I understand, however the chances of them doing any major harm is slimmer if they can't sit in the server for like 20 seconds running commands or get to actually load into the server.
It's a much better method to drop them rather than ban their ip, the problem was that if a client was banned on one server then decides to go to another server before the list is updated they could slip right in without the passwordauth hook being able to catch them so the only way to prevent that would be to query the database every few seconds which is rather wasteful and dumb even if it is a locally hosted database. The banlist would have been preloaded on mapload anyways otherwise it wouldn't exist for the first client.
Now if I could only get all the clients to stop crashing out when people are kicked or banned randomly, it seems to happen with kickid and gatekeeper..
If anything, I would frequently query the ban table for new bans, deny a connection attempt if either the reported steamid (keep in mind, this will not always be provided) OR ip is banned, and then in PlayerAuthed check again as well as run a threaded query as you do now in PlayerPasswordAuth to catch anybody trying to game the system.
EDIT: In respose to your earlier post, the userid cannot be provided in PlayerPasswordAuth because the userid simply hasn't been allocated for the user yet. I suppose it could be possible to pass the userid next in line to be used, but it seems an ugly hack at best. AzuiSleet's UserByIPAddress function is as good as it is going to get as the IClient isn't assocated with a steamid until the steam callback is received.
Well, with AzuiSleet's addition of GetUserByAddress, you should be able to get everything working now.
Going off on a tangent, I don't think you're giving your database server enough credit. If you update it every 5-10 seconds with a threaded query (set up to select only bans that have been added since the last check) I think you'll find your performance unaffected. I have a P2 333 that putts right along with a sizable database and can get hit with multiple queries per second. The distance between the servers will really only affect the time it takes for your callback to get called, but I'd say that it's better to have your cached banlist out of date by a few seconds than it is to never update it until after you could have already used it! (Especially since it would allow you to more effectively block commands from being run, which seems like a big concern) I suppose there's probably more to it than that, though.
Even when commands come in I still have other things as a protection such as SLog or Cvar2.
Actually, it seems as though almost every time a client is dropped while being in the server all the clients crash out. Gatekeeper.Drop() seems to do it more than kickid ever did...
Argh, why is Garry's Mod doing this now, I think it started happening after that one update where Garry added the new voice hud item.
I'll try to look into this more later, it's getting too late for me.
error loading module 'gatekeeper' from file 'c:\_x\lua\includes\modules\gmsv_gatekeeper.dll':
%1 is not a valid Win32 application.
Edit: SVN Version.
The 3.1 seems to work fine for me (the zip file)
Tried on my other DEDI too, not working :!
fixed it and nice module
New version of gatekeeper has been released. Linux support has been added and some of the internals have been cleaned up.
Anybody interested in the makefile can take a look at the repo; it goes into the linux_sdk/ directory of the source sdk after some obvious changes to the main makefile. Everything was built with gcc 4.3.
Did you fix the memory messup where clients end up dropped with the gamemode name as a reason on connect?
If you can provide a way to reliably reproduce it, I'll look into it, but for now I'm fairly certain that fault lies with another module or script.
gatekeeper.GetUserByAddress() doesn't seem to be working.
When it should be kicking players on a secondary check it just returns nil.
Code:> print(gatekeeper.GetUserByAdress)... nil > print(gatekeeper.Drop)... function: 02DD2850
Code:> print(gatekeeper.GetUserByAddress)... function: 026CD508
Can't exactly replicate it. However, it did stop after removing gatekeeper. It only happened occasionally, on initial connect.
Woops, well gatekeeper.GetUserByAddress seemed to have been returning nil when checking for any recent connections by banned players after my ban list is refreshed.
I might have been using a really old version of gatekeeper some how, I'm not really sure.
I've updated gatekeeper to work with the source 2009 version of gmod. Do not attempt to use 4.1 with a server that isn't running the beta as it will probably crash on startup (or on first connect). This version should be compatible with the next update, whenever it comes out.
Linux binaries will follow as soon as gmod linux binaries for source 2009 are released.
GateKeeper has been updated with code necessary for the detection and removal of clients that using tools such as Tranquility to spoof their steamid. Not perfect, but the best solution available until valve patches it for good (not long now that they have a working POC in their hands).
The latest version of gatekeeper has been misreporting the number of players. I clearly had 15 players in-game and connecting (reported by HLSW, and any viewing tool) but gatekeeper:GetNumClients().total was reporting a few players less than that. This happens every time.
Can't remember if this was mentioned or not.
Can this module in any way be used for kicking people from the server once they're connected? Or do I have to use ply:Kick()?
And, since it can't really be repeated often enough, DO NOT use the player's entity after calling gatekeeper.Drop.
Thanks. Was just checking so I wouldn't end up crashing the server using a method the way it wasn't intended.
And I'm ignoring that comment, raBBish.
Funny how that happens, actually. When yer listening to a conversation and IM chatting at the same time, then you just write a random word from whatever you're listening to.
Excuse me, please fix GetNumClients()