As a Roblox developer, I would like the documentation of the GetArrivingTeleportGui method of TeleportService to state the necessity of performing checks on the teleport GUI before inserting it into the PlayerGui object, because the GUI can come from a different game, which might insert unwanted content.
The current documentation provides the following sample code:
As you can see, no check is performed on the GUI, neither on the source game ID (obtainable via the GetJoinData method of the Player object. That means, if a different game sets the teleport GUI and then teleports to the game having this code, they would have this GUI on their screen for 5 seconds.
I would have appreciated if this warning was present before, as a kind person just let me know about a vulnerability in my game because of the lack of check on the provenance of the teleport GUI.
On a side note, I would like to highlight important details that makes the checks difficult to make:
Using GetJoinData on a local script always returns nil in the field “SourceGameId”, no matter if the player came from a teleport from the server or the client, and no matter the game where the player comes from.
Unlike what SetTeleportSetting documentation states about persistence of settings, the values DO persist between games. That means, other games can carry teleport settings to another game.
That’s a terrifying undocumented feature if true. Teleports are important to my experience and right now I insert any arriving teleport gui as long as one exists because I carry the assumption that the only teleports happening to my experience are from me alone. Looks like I’ll have to reconstruct my static teleport screen instead of assuming GetArrivingTeleportGui returns my own.
There’s nothing that can really be done about the screen being shown in transit, that’s on Roblox, but at the very least I don’t want to further propagate another experience’s teleport gui for any reason, whether it’s inappropriate content or branding from another experience.
I feel like GetLocalPlayerTeleportData should be used for validation purposes over GetJoinData since it’s still a Gui at the end of the day. Any dice with validation using that instead?
I don’t feel like trying to use GetLocalPlayerTeleportData, because then I would have to always include in all teleports some data for controlling the provenance, which I find annoying to do. It should not be up to us to handle that.
It’s worth noting that GetArrivingTeleportGui only returns an instance if the teleport was initiated by another place in the same game, so this really shouldn’t be an issue.
That’s what the documentation states, but the actual behaviour is different, as I explain in my first post (and the second post too with SetTeleportSetting)
Do you mean to say that the documentation incorrectly states that this only applies if the teleport occurs within the same experience? If so, maybe you should make that clearer in your original post, because my understanding was that you believed this could be caused by teleports from a different game.
If the behaviour doesn’t match the documentation, this should probably be filed as a bug report instead of a documentation request. It would be better to improve how the backend displays a TeleportGui in transit than to change the documentation so everyone could benefit here automatically. That’s on me for missing that part of the post/documentation.
At the very least I can see that this would likely only affect the start place since you have the option of turning off joining and teleports to other places in an experience, so it feels as though right now you would just have to make a single check on the source. Though Roblox shouldn’t allow, through normal operation, TeleportGuis and settings to another developer’s experience.
