P A P A
B L E S S
i miss you brad
1 Like
I understand the limitations of the API, but until the data is sent via Server to Server, completely bypassing the client, I’m not going to feel very safe relying on this form of data transmission. Even if the data is encrypted that’s still not a guarantee that exploiters will never be able to find out how to decrypt it and tamper with it. Exploiters are relentless and for something as important and sensitive as the user’s data, I’d rather use safer methods of handling it.
Other than that, thank you woot. Very cool.
2 Likes
I have the same concerns. I don’t trust the client.
I don’t really understand the issue here.
The exploiter can only read their own data. Any attempt to change the data will result in it not being sent.
What sort of sensitive data are you sending?
Assuming this was implemented how I think it was, this isn’t possible.
The server signs the data which it sends to the client. Tampering with the data would make the validation on the server fail (resulting in nil).
2 Likes
An example of this would be the server telling the other server where the player is spawning (e.g. zones of a world). If some zones are locked, you obviously wouldn’t want exploiters teleporting to them. Problem is, if the data is nil, the server would just have to kick the client. This can lead to undesirable results in say matchmaking.
If it was purely Server -> Server, we wouldn’t be facing this issue.
It’s the same issue as trusting the client with direct access to datastores, while it can be secure, all it takes is someone finding a way to bypass the client validation to cause destruction.
2 Likes
I’m not sending any data, or using this feature at atm lol. I’m speaking theoretically. Of course for now if they try to tamper with anything it won’t be sent, I’m simply raising an eyebrow at the possibility of successfully tampering with data in a way that won’t be caught. The likelyhood of that happening when part of the route is done on the client than the server is higher. Everything is secure until someone finds a way to break into it.
1 Like
If your matchmaking can handle players that drop while they’re teleporting (because they closed the game or whatever), it should also be able to handle players that are kicked because their teleport data is nil.
1 Like
I understand that. I’m just not comfortable with the server data being entrusted to the client.
So, I’m not sure if this is how this was implemented, but this is probably pretty similar:
The server has some sort of secret string stored on it. It signs the data with that string and creates a hash. That’s the “signature” bit. Once it receives your data from the client, it signs it in the same way. If the generated hash doesn’t match the sent hash then the data must be invalid.
The only way to break this system would be to know the secret string (which could be several hundred characters long)
JWT uses SHA256, if you’re wondering why you can’t just use bruteforce:
6 Likes
Going to have fun with this update, actually suits my plans a little better. <3
Woohoo! Even more easy to make multi-place games, might go and work on an older project as a result 
Hi all,
The changes to this method are now documented on the Developer Hub.
https://www.robloxdev.com/api-reference/function/Player/GetJoinData
We reccomend you consult this page before using this function, as it contains additional information about the security checks applied.
3 Likes
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.