Unfortunately does not work. Gives an error saying “attempt to index nill with name”
1 Like
Can you copy me the output or take a screenshot?
I know, but your remote event literally opens a gate for that.
1 Like
I’m guessing the problem is from the part variable.
It seems like the script hasn’t recognized that variable as PART very well.
Make sure that the variable is your part.
Double check it.
1 Like
I think it does not recognize my player name, and instead gives nill. This is the exact same error that happened before.
1 Like
Yes, sadly as it is possible for client to get access to Replicated Storage, but that requires a protection system as well.
Here it is:
Many posts have talked about this:
And like I said, exploiters cannot really do anything:
1 Like
You sure that the parent of the script is a button?
Also try debugging with print(), so you could find out player name… part name… etc.
Print out those things, it might be helpful.
1 Like
Yes, it is a button. I have also tried printing, and it always stutters at the player name. Gives that “nill” error I mentioned.
1 Like
You are missing my point. The exploiter can literally just fire your remote event with whatever model/part they want gone, and boom, destroyed.
That could be solved by just adding some extra security statements when firing the part along with it.
Plus, nobody said this project he is working on is going on public so fast at first time.
They will add extra anti cheats… etc, once they are finished.
So what makes you worry about a non-finished script on a private game?
Because the code has a serious security flaw, which you mentioned nothing about, and could have gone unnoticed.
It looks a like a cake.
You got to make the cake first, make it EXIST.
Then you add extra things.
As the topic title said, it requires a help in part deletion, not security stuff.
I believe in the ALPHA version of the project, these bugs, lack of security should be checked.
So not really, it will be noticed.
We have to discuss what part of the script is his PROBLEM.
Not extra things.
It doesn’t matter, this is a case of where someone who doesn’t know any better might not notice a problem like this. Finished product or not, you shouldn’t be giving out advice which will be a problem in the long term, if not changed(which probably wouldn’t have happened if no one pointed it out). The least you could have done was to state the fact that it is not secure.
1 Like
If you really want to be helpful, try to fix the issue as I am doing so?
Got any idea how to fix the protection lack?
Thank you for your help, I modified the script slightly, and it works as intended.
1 Like
Rather concerned about this, any way to fix this issue?
Here’s a sanity check, there shouldn’t be any security problem anymore.
Local script:
local RemoteEvent = game:GetService("ReplicatedStorage"):FindFirstChild("RemoteEvent")
script.Parent.MouseButton1Click:Connect(function(player)
for Index, Part in ipairs(workspace.Aircraft:GetDescendants()) do
RemoteEvent:FireServer(Part)
end
end)
Sever script:
local RemoteEvent = game:GetService("ReplicatedStorage"):FindFirstChild("RemoteEvent")
RemoteEvent.OnServerEvent:Connect(function(PlayerClient, Part))
if Part.Name == PlayerClient.Name then
Part:Destroy()
end
end)
Edit: accidentally pressed send lol I’m on mobile
2 Likes
Why are you getting mad when I am pointing out a serious flaw with your code? I don’t think you quite understand the magnitude of the flaw. It allows you to remove all parts in workspace, kick all players. It allows you to essentially lock the game.
Either way, to fix it, you could define the part you want to remove on the server, which makes sure the only part you can remove is the one you are supposed to. Alternatively, if there are multiple parts that need to be removed, you can send a string identifier in the remote event, instead of the Part/Model instance.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.