Due to a large amount of script changing(allows you to joinbattle as anyone else as long as you set it up, this is trivial and takes a few lines of code.) , We need to add a security parameter to the game. Unfortunately this takes a bit of effort, as it is fairly complex.
What i am proposing is that prior to the autohost launching spring, it sends a PM to your client(any flavor, would require cooperation between devs) with a unique ID. Then this unique ID is included in your start script, which in turn is sent to the the server hosting the battle(who sent you the code originally).
This would add an appropriate amount of security to solve this issue.
It would require all lobby devs to add a command to parse out and not show the user, something like #$#125235155#$# as a private PM, but not shown in the actual client.
It would also require a modification to all hosting abilities, so that the uniqueIDs where ALL included when you hosted, so that when passed to spring they can be verified, which brings us to:
It would require a modification of the spring application itself, to accept unique numbers associated with users.
None of this is that complicated and would improve gameplay around here alot. The other day someone was spot stealing for hours on many servers and it was quite irritating.
function gadget:GetInfo() return { name = "NoStartPointStealing", desc = "Prevents start point spam / stealing", author = "TheFatController", date = "Jan 18, 2009", license = "GNU GPL, v2 or later", layer = 0, enabled = true -- loaded by default? } end
-------------------------------------------------------------------------------- -------------------------------------------------------------------------------- if (not gadgetHandler:IsSyncedCode()) then
local startPoints = {} local BLOCK_TIME = 2.5 local BLOCK_RANGE = 430
local function getDistance(x1,z1,x2,z2) local dx,dz = x1-x2,z1-z2 return math.sqrt((dx*dx)+(dz*dz)) end
function gadget:GameStart() gadgetHandler:RemoveGadget() return end
function gadget:MapDrawCmd(playerID, cmdType, px, py, pz, label) if (cmdType ~= "point") then return end startPoints[playerID] = {time = Spring.GetTimer(), x=px, z=pz} end
function gadget:MousePress(x, y, button) if button==1 then local _,coords = Spring.TraceScreenRay(x,y,true,true) local dx,dz = coords[1],coords[3] if dx and dz then for playerID,defs in pairs(startPoints) do if (Spring.DiffTimers(Spring.GetTimer(), defs.time) > BLOCK_TIME) then startPoints[playerID] = nil elseif (getDistance(dx,dz,defs.x,defs.z) < BLOCK_RANGE) then return true end end end end return false end
function gadget:MouseRelease(x, y, button) return false end
end
(from my 'spring crap' folder, not written for anything in particular)
uh sef, those are implemented in spring... and you can only guarantee *sending* of spoofed packets... you can't necessarily expect to get anything back.
packet spoofing could override the IP address issue.
There's no way to spoof active IP connections, since traffic has to return to the "right" address.
Can someone define "Spot stealing" exactly? It seems like people attempting to spawn on top of each other could be solved by a Lua gadget that establishes a minimum distance to the nearest other player. Then, you could just wait until all players are in game and given them a random order to chose start spots.
Another option would be a new gametype of "Choose pre-selected spots in game" where the only valid spots would be start positions included with the map in the host's startbox.
packet spoofing could override the IP address issue.
There's no way to spoof active IP connections, since traffic has to return to the "right" address.
Can someone define "Spot stealing" exactly? It seems like people attempting to spawn on top of each other could be solved by a Lua gadget that establishes a minimum distance to the nearest other player. Then, you could just wait until all players are in game and given them a random order to chose start spots.
Another option would be a new gametype of "Choose pre-selected spots in game" where the only valid spots would be start positions included with the map in the host's startbox.
Spot stealing is where you forge script.txt and connect as a different player. This lets you play when you were just a spec (or even not), kicking someone else out of the game. It has nothing to do with start positions
So the information in your script.txt telling your client which team number etc you are is changed to that of somebody elses, coupled with connecting and loading before they do means when they do finally connect their slot is already full and the server boots them?
hmm is all this data not available to the lobby running on the hosts machine? Hence meaning that all the data needed to double check the client is present on the host already?
The lobby server should pass the IP / names of the clients to the host so it can automatically assign people to slots as they connect. Why bother with something complex like unique IDs when IP addresses will work and be "unhackable"?
So the information in your script.txt telling your client which team number etc you are is changed to that of somebody elses, coupled with connecting and loading before they do means when they do finally connect their slot is already full and the server boots them?
Yes.
Quote:
hmm is all this data not available to the lobby running on the hosts machine? Hence meaning that all the data needed to double check the client is present on the host already?
By default the client sends only public data. Double checking that is useless if no authentication is used.
The host should be handed IPs of all connecting clients then
+1.
I mean, it's not like would-be hackers aren't 100% able to get those IPs from the start, so it's not about security or privacy. If people are that paranoid about people having their IPs, they can use a proxy.
The host should be handed IPs of all connecting clients then
+1.
I mean, it's not like would-be hackers aren't 100% able to get those IPs from the start, so it's not about security or privacy. If people are that paranoid about people having their IPs, they can use a proxy.
Passing IPs is just as difficult as passing a unique/secure token. The token seems like it might be more robust (eg 2 players behind a nat having same ip, or situations where spring connects differently than the lobby client)
The host should be handed IPs of all connecting clients then
+1.
I mean, it's not like would-be hackers aren't 100% able to get those IPs from the start, so it's not about security or privacy. If people are that paranoid about people having their IPs, they can use a proxy.
Using a proxy for lobby breaks this, if the springs connects directly (host sees different IPs). Using a proxy for spring will increase latency - no one wants this.
For authentication you better use something you don't reveal by connecting to the lobby.
Checking IPs is afaik not yet implemented, a password check is.
Also I think the IP and MAC address of players should be recorded in replays, probably as some sort of hash combining both. This would let the moderators easily track said users and ban them from the lobby.
Joined: 24 Jun 2007, 07:34 Location: 50┬░ 56' N, 11┬░ 35' O
el_matarife wrote:
Also I think the IP and MAC address of players should be recorded in replays, probably as some sort of hash combining both. This would let the moderators easily track said users and ban them from the lobby.
I wanted to add the IPs (MAC is useless) to the infolog, but was defeated by bawwwing of random people concerned about "security".
Infolog for host only seems reasonable, they can easily get the IPs anyways.
that is no valid argument for security concerns. it is like saying ISPs should store/give out info about their clients (eg IPs) however they want, cause they can get that info.
Users browsing this forum: No registered users and 0 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum