Serverside method of getting player teleport data

Hey Developers,

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.

107 Likes

Literally have to recode an hour of work I just did, perfect timing though because I was just thinking about needing this like 5 min ago.

https://www.robloxdev.com/api-reference/function/Player/GetJoinData should be updated to show this (and also clarify this method only works on the server).

8 Likes

The documentation should be updated soon.

4 Likes

VERY nice, I can definitely use this.

5 Likes

Just as I finish a validation system for Client Data

THANK YOU SO MUCH

4 Likes

Will this work to / from servers in a different universe?

1 Like

THANK YOU SO MUCH! I’ve been waiting for this for 2+ years, AWESOME! :smiley: :bow:

3 Likes

Wait, so is the data still server side or is it client side?

Yes, this is why SourcePlaceId is present, so you can validate the origin of the data.

1 Like

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

1 Like

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?)

2 Likes

This is an awesome addition: One less remote I have to occasionally string together.
THANK YOU!!!

1 Like

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.

4 Likes

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.

6 Likes

If I had to guess, this is probably how teleport data is securely transmitted from the source to destination:

  1. The join data is encrypted on the source server and transmitted to the client.
  2. The encrypted join data is carried by the client to the destination server.
  3. Upon arrival, the encrypted data is sent by the client to the server for decryption.

It seems secure enough for me. If the player’s TeleportData is nil (because the decryption failed or whatever), you can always kick them.

If you want to prevent the client from reading the data, try encrypting it on the server yourself.

1 Like

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.

4 Likes

But if the client modifies the data, then the data on the server is going to be nil. Just kick them at that point.

2 Likes

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.

4 Likes

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.

3 Likes

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.