That’s a relief for my admin panel! I was securing my remotes with a UserId check for the calling player, but because of my paranoia, I generate a pre-shared key which was a bunch of GUIDs strung together It was >10 GUIDs together. Good thing I won’t need that.
2 Likes
An admin panel? That shouldn’t be even viewable to the client at all.
I think you should have scripts under the admin panel that operate on it, so that it’s only activated when it’s parented to a space that can run those scripts, like a player’s ‘PlayerGui’ for example. So you can put the panel in ‘ServerStorage’, and then listen for players to join on the server, and if their id matches up, parent the admin panel to their gui, this way clients that are not admins or anyone authorized do not even see the existence of the admin panel. As such, you don’t have to worry about your panel’s remote security
1 Like
I already did that, albeit slightly differently. I parent the panel in my server-sided Script in ServerScriptService, but the rest is identical.
A hacker could still fire the remotes without the panel, as they’re located in ReplicatedStorage, which is replicated to clients.
I am pretty sure if you clone the UI from server you can have remoteevent inside of it so it will be parented directly to your UI and only Server and you are gonna see it which allows you to have “not replicated remote to all clients”.
Impossible. The server can’t access a client’s GUI according to this little snippet:
(This article on the DevHub, if you’re curious.)
Hey, I’ve made quick repro place for you to see that it is actually possible.
PlayerGuiRepro.rbxl (32.7 KB)
And in official DevHub article there isn’t anything about not replicated across Roblox’s server/client boundary. PlayerGui (roblox.com)
Or you could secure your remote events like a normal person rather than taking the most obscure and janky routes possible.
While I agree with you I was referring to my previous quote:
That’s not a janky route though, that’s genuinly just contextually locating your remote. In this case, the average client has absolutely no reason to see that remote, so then they will not see it. Otherwise you’re just wasting memory
and @AlphaEpsilon290
Impossible. The server can’t access a client’s GUI according to this little snippet:
That’s correct, that’s why you have a Client script in there too, that’s why it may look like this:
Upon being parented to a player’s gui, both the server and the client script will run, commencing the admin. And because all of this info is isolated solely to the gui, and the gui does not exist to any other player, it is then perfectly secure.
No, I think this just means that any changes to the gui on the client do not replicated to the server.
Yes it is. Your relying not on your own code, but on Roblox’s replication, which could change at any time, or have some random undocumented feature.
An if statement works just as well, and requires much less thought.
Doing stuff like this is essentially over complicating a what would be simple task, that has much less areas it can go wrong.
but on Roblox’s replication, which could change at any time, or have some random undocumented feature.
That is absolutely fair, if it applied here. Which I don’t think it does, the current state of ServerScriptService and ServerStorage is that they are absolutely isolated to the server side, even back in the days of Filtering enabled being toggleable, you still couldn’t see server side things. So roblox will likely never change that core expected behavior enough to break it to any measurable degree.
An if statement works just as well, and requires much less thought.
Doing stuff like this is essentially over complicating a what would be simple task, that has much less areas it can go wrong.
I say the exact opposite, when you keep something on server side, you expect it to only be visible to the server, when you put it on the client, you expect it to be visible to the client and sometimes the server as well. That’s extremely simple, however you can complicate it by taking it out of the space that’s supposed to only be server-side, giving it to the client for no reason, and dealing with the implications of that. Is that not complication? And even then, although this relies on your own code, it’s still subject to the exact same implications you mentioned, maybe more so even, the way they handle UserId may change.
I dont want to make a seperate post just for this question, but can an exploiter fire a remote event to all clients? Or just to the server.
they can only fire remote events to the server. However, if you make a remote event fire all clients via code on the server inside the said remote then the exploiter can simply fire from the client that remote event which in turns fires the other ones
1 Like
UI management should not be done on the server. The path you are taking is bad practice. Just have the GUI in ReplicatedStorage or in StarterGui, and then validate incoming requests on the server.
You should not take certain paths that may seem quicker just because you can.
This isn’t “UI management” like what you’re referring to. This is an admin gui that will only be parented to people who join and are deemed as an admin. That is why it is managed on the server, if it were managed on the client, the client would be able to see it and do as they please with it. But, since only admins will have it parented to them, it will be managed by their client afterwards.
The entire point of my post is that there is no need whatsoever for the average client to be able to see this gui, not only is it a waste of memory but exploiters will be able to see it. And securing bizzare admin usage can take quite a bit of time in order to not be abused. But, had you just taken the two seconds to only register it’s existence on the client when that person is the person who needs it, that’s subverts everything else that was previously required
It is though. You’re managing the existance of the UI on the server, when the server should only be used to allow the client to fire actions which replicate. The client on the other hand should be responsible for managing the interface and experience of this communication. If you’re too worried about memory, simply destroying the GUI on the client can suffice.
You’re managing the existance of the UI on the server, when the server should only be used to allow the client to fire actions which replicate.
What does an arbitrary rule matter when following said rule is worse than if you didn’t? It’s worse in this case, since again it would take far longer and be worse if you let everyone see it, whereas it’s 2 seconds to just have it inactive sitting in server storage, and then clone, parent when needed.
I have the feeling you aren’t visualizing what i’m saying too well, caviarbro's repro file in the post linked below is exactly the approach I am talking about.
Anyway, I think we’re going off topic now for long enough, if you wanna pick this back up feel free to dm me 
1 Like
Sorry for bump, just wanted to point this out.
Clients are actually able to access other peoples UIs from my experience. You have to protect the RemoteEvent regardless. All it is is a new location, and it’s making no difference. Sure you could do that to minimize visibility to the Remote itself, but that doesn’t mean it’s “fully secure”.
It’s just like having it in ReplicatedStorage hiding in a folder. It’s still downloaded to the client.
Reason I know other UIs are accessible from the client is because I’ve tested similar situations before within studio (which acts just like any exploiters powers would be like local)
Protecting is important regardless.
no_gui_repro.rbxl (33.3 KB)
Please make sure your experience is actually correct.
All it is is a new location, and it’s making no difference. Sure you could do that to minimize visibility to the Remote itself, but that doesn’t mean it’s “fully secure”.
Generally true, but you’re ommiting too much detail here. If in no possible case, will that remote event ever be replicated to anybody besides a player determined by the server to be valid, it is by all intents and purposes; secure.
It’s just like having it in ReplicatedStorage hiding in a folder. It’s still downloaded to the client.
It’s not like that at all, unlike ReplicatedStorage, PlayerGui is not replicated to other players. If it were, it’d be a HUGE engine flaw, as tons of bandwitdh would be used when players update their gui, it may even make the game unplayable.
Reason I know other UIs are accessible from the client is because I’ve tested similar situations before within studio (which acts just like any exploiters powers would be like local)
Again, if you’re going to present these claims to other people as evidence, please re-test them and submit your findings as evidence.