When a message is sent, it creates a new entry in the express._awaitingProof table, using the hash of the data (prefixed with the recipient's Steam ID, if called serverside) and then removes the entry from the table when proof is received.
But what should Express do if the same message with the same data is sent multiple times in a short timespan?
I suppose the expected behavior would be to get a callback for each message sent, but right now it'd only run the callback once (the first run would remove it from the callbacks table).
Perhaps we could make an incrementing transactionID that would get automatically sent and incremented with each message, and then use that number in the key for express._awaitingProof. Then, the recipient would reply with same transactionID we sent them, and we'd use that to run the correct callback.
We could implement this in transparently so the user doesn't have to worry about it, but I worry this could create a maybe-exploit where a malicious actor could reply with a different transactionID, potentially running the wrong callback. Granted, it would still be prefixed with their SteamID, so they'd only be running a callback we already expected them to run.... I dunno.
Just a braindump for now, will revisit when some of the more pressing tasks have been completed.
Here's the bit of code in question: https://github.com/CFC-Servers/gm_express/blob/main/lua/gm_express/sh_init.lua#L131-L141
When a message is sent, it creates a new entry in the
express._awaitingProoftable, using the hash of the data (prefixed with the recipient's Steam ID, if called serverside) and then removes the entry from the table when proof is received.But what should Express do if the same message with the same data is sent multiple times in a short timespan? I suppose the expected behavior would be to get a callback for each message sent, but right now it'd only run the callback once (the first run would remove it from the callbacks table).
Perhaps we could make an incrementing
transactionIDthat would get automatically sent and incremented with each message, and then use that number in the key forexpress._awaitingProof. Then, the recipient would reply with sametransactionIDwe sent them, and we'd use that to run the correct callback.We could implement this in transparently so the user doesn't have to worry about it, but I worry this could create a maybe-exploit where a malicious actor could reply with a different
transactionID, potentially running the wrong callback. Granted, it would still be prefixed with their SteamID, so they'd only be running a callback we already expected them to run.... I dunno.Just a braindump for now, will revisit when some of the more pressing tasks have been completed.