We’ve just enabled an awesome new feature for you!
This feature allows you to safely transmit data from one server to another during the teleport process without the need for datastores.
How does this work?
When you call any teleport method from the server the data, which you supply for teleportData, will be accessible via the GetJoinData method under the field TeleportData
Since we transmit the data alongside the client there are a few things you need to keep in mind.
Data that you send cannot be tampered with by the client.
Data that you send can be re-used by the client at a later time.
The SourcePlaceId field will correctly identify the place where the data was generated.
But wait, there’s more!
Along with the addition of the TeleportData field, the SourcePlaceId field will now be present for all forms of teleport while the Members field will only be present when teleporting via the TeleportPartyAsync method.
The data is only present in server side teleports, the client is just used to transmit the data. You can access the data on the client with GetLocalPlayerTeleportData
I’m still a bit confused -
So the data is stored server sided, but the client has read only access to the server sided data? Could an exploiter potentially somehow stop the transmission of the data if the client is used to transmit it (and is it actually server sided?)
The documentation will explain the process in much more detail as soon as it is available. To briefly answer your question, the client is merely used as a mode of transport to pass the data from the origin server and the destination server.
Exploiters can take advantage of this to some extent however we have also mitigated certain attack vectors to ensure this is a useful feature.
If exploiters alter the data, TeleportData will be nil.
If exploiters refuse to give the data to the destination server, TeleportData will be nil.
There is one case where this is not true and that is when an exploiter re-uses data given to them by a server from a previous teleport.
Will there ever be plans for direct Server -> Server communication, and if so, will this feature implement said Server -> Server communication when it is developed?
I feel as if though this is just a band-aid to the much larger problem : The whole point of server sided teleport data is to prevent the client from reading/editing the data. This new method just changes how the data is transported, it still comes into contact with the client at some point thus having a vulnerability to exploitation.
It’s the same thing as using regular client teleport data, the data can still be nil if an exploiter modifies it.
I want to prevent the client from even modifying the data, period. Hence the need for actual Server -> Server communication. Much the same reason as you wouldn’t trust a client with access to datastores.
Yes I agree with you, but I wouldn’t need to kick them if the data was purely server side (e.g. player’s data, or a map location that they are being teleported to).
And for games with matchmaking, pure server sided data is a need in some use cases.
Due to the current implementation of the teleport API this data needs to be transmitted with the client. If the API is revised in the future then it’s a possibility that Server -> Server communication might be possible.
If the client modifies this data then it will be invalidated and TeleportData will be nil. As long as you know what format of data to expect then you can be certain that if data does not arrive in that format then the player has attempted to modify it.
If you’re looking for something more secure then you should use data stores.
Honestly there isn’t a HUGE security worry with teleports as you make it out to be. The security mentioned above seems perfectly fine seeing as the client is the one changing servers.
