When will 'GetPlayerIdentifiers' be fixed?

FiveM Resource Development & Modding
1

There’s a couple of issues with this function, and most of them can be worked around with, but there’s one in particular that makes this function unreliable when used on event ‘playerConnecting’. The issue I’m talking about here is the function returning identifiers for a player that connected previously.

        static Client FindPlayer(int source)
        {
            return ClientInstances.Clients.Where(a => a.Value.NetID == source).Select(a => a.Value).FirstOrDefault();
        }

Should probably make this function more fail-safe for something that is so vital. Right now, on servers that white-list by steam id on connect, people that aren’t supposed to be able to connect can just come right in.

2 
AddEventHandler('playerConnecting', function(name, setCallback)
	local identifiers = GetPlayerIdentifiers(source)
		for i = 1, #identifiers do
			local identifier = identifiers[i]
			local banned = checkBan(identifier)
			print("Essential | Checking user ban: (" .. name .. ") " .. identifier)

			if(banned)then
				if(tonumber(banned.banned) == 1)then
			  		setCallback(banned.banreason)
					CancelEvent()
				end
			return
	    end
	end
end)

used on essentialmode, works fine.

3

At this point a client has a TempID, which is a workaround for a regression caused when player management was redone to fix cases where dead clients would be assigned session arbitrator. Whatever code you posted is for an outdated version of CitizenMP.Server.

There’s no easy way to reproduce this issue in our local testing environment, but we are aware it does occur - it however isn’t easy to fix either, so at the latest (unless a repro case comes falling out of the sky) this’ll be fixed at the first stage of the implementation of OneSync.

4

Thanks for recognizing it exists and that there’s a fix coming. I have other measures to prevent people from joining, but I still print() the onconnect identifiers and I occasionally see people connecting with my steam ID (the first to join the server). I’ll see if I can figure out a repo case…

5

R&D has discovered a potential race condition in assigning TempIDs, this is fixed in internal commit d0fd317b which should reach general availability within the next while or so.

6

@magnesium @ytterbium
On my server it pretty much copies the identities (steamID or IP, doesn’t matter) of the previously connected person more than it doesn’t. It keeps doing this for every connection established:

Player A (Ident A)
Player B (Ident A)
Player C (Ident B)
Player D (Ident C)
…etc…

I discovered that once a client times out OR is rejected from the server, the next person connecting will have the right identifiers. As such you can circumvent this bug by remembering the identifier that connected last and compare them with the identifier that are currently connecting, and if they are equal you drop the connection with the message to try again, for example.

@Kanersps @Mr.Scammer @Lex_The_Great @Slluxx

local lastConnectedIdent = nil
AddEventHandler( "playerConnecting", function( playerName, setCallback )
	local ident = GetPlayerIdentifiers( source )
	
	print( string.format( "'%s' connecting. (%s)", playerName, table.concat( ident, ", " ) ) )
	
	if lastConnectedIdent ~= nil then
		if ident[1] == lastConnectedIdent[1] then
			lastConnectedIdent = nil
			setCallback( "Please try again" )
			CancelEvent()
			return
		end
	end
	
	lastConnectedIDent = ident
end)

It’s not a repo case, but I hope this information will give you more insight into the origin of the bug.