I can never recall using a third party module for any serious code base.
I still request a way to block Third-Party module requires.
8 Likes
In that case the message will only print in a live server.
3 Likes
Can this not appear if we give a plugin access to inject scripts?? Incredibly frustrating having this spam my output when play testing
4 Likes
I am aware of how IsStudio works, and Iâm aware of the code being ran only in live servers in such a case too. What Iâm not aware of is if we are going to be given tools that would let us locate the requires running only when IsStudio is false, and thus showing up in the live server console - right now, the most information we would be able to get is the location of the script. Unfortunately, thatâs not enough, as scripts like this are often located in places like âworkspace.Model.Model.Part.Scriptâ. Finding the require ID using the find & replace tool is pointless too, as backdoor authors resort to hacky ways such as using hexadecimals, or even unicode char codes put in string.reverse(). Thatâs what I said in the second sentence of my post that youâve (partially) quoted.
2 Likes
How will this kill all script builders?
2 Likes
Great feature! This actually helped me find a backdoor I didnât even know was in one of my games that the map developer had accidentally slipped in.
1 Like
If you have require access you can just log all input anyway?
1 Like
Is there any way to disable this feature?
Some of the plugins I have rely on require and itâs spamming my output on every play test.
3 Likes
This is great. It will help protect against backdoors in the future
This is a great feature for those who might have accidentally stumbled across a backdoor but could be able to disable this? It floods my output in one of my games I am working on and gets pretty annoying.
1 Like
Youâre donât make any sense. You claim all of the scripts would be âopen sourceâ, but back up the point no one will be able to see itâŚ?
2 Likes
So your script builder is sandboxing require?
2 Likes
Yup I do know that, when you execute a script in a script builder it will require and send a require print like if it was a normal script and you could just use LogService and hook that and some noob can just straight up steal your require in 2 seconds.
1 Like
I donât think you understand why she said that.
By no means is Automationeer suggesting that your sole anti-exploit should be client-sided or should be dependent on obscurity. Developers on this forum have repeated those ad nauseam that a lot of people know by now not to rely on it.
Hereâs the thing though: not all exploiters spend a dedicated amount of time exploiting your experience, handcrafting workarounds or anything of the sort. Like novice scripters, casual exploiters arenât thinking that deeply about what theyâre doing and just following whatever they see.
You can stop an ample number of exploiters on their side with a few client-side checks or honeypots that entice them to invoke something and instead get hit with a countermeasure of some sort, be it a disconnection from the server or a ban. By all means you should be trying to stop exploiting as much as possible from the server, but itâs ideal to get that extra bit of security by also doing a few things on the client. It wonât stop everyone but it will stop someone. Mitigating exploiting is as valid a step to countering exploiters as patching, if patching the exploit in question is possible for your experience.
You have the right thought that developers should stop being obsessed with security through obscurity but that has little to nothing to do with what Automationeer said and youâre confusing both obscurity and client-side anti-exploitâs usefulness in general.
Also please, please stop it with this âif your game was secure by design youâd have no problemsâ nonsense. Provide actual tips here instead of telling people that their experience isnât secure by design and thatâs why theyâre having problems with exploiters. A lot of us have either pretty simple or deeply intricate anti-exploits and weâre still facing problems. Tackling anti-exploits should be a collaborative effort within the developer community and saying this doesnât help anyone.
5 Likes
Will there in future be the return of private modules? I understand they were used to exploit games and cause mayhem as well as better protect games.
Is it not possible for it to be private within your own game?
4 Likes
If the game was created under your account/group and the module as well, you can require it. Otherwise, it has to be open source or the user has to own the module to require it.
1 Like
This is a step forward in the right direction, but I feel like as others have stated in this thread, we need a dedicated way to look up required modules as the output can get cluttered easily.
On a semi-unrelated note to this change, I also think the following changes would be good for the remote part of require():
- Being able to have a game setting where assets have to be whitelisted before you can require them, otherwise they will not run.
- Please let us require modules from groups that we have toolbox access to. A lot of my work is based around private modules being required and due to the change made to Modules in 2019, I had to either purchase the modules and have them in my inventory, or use InsertService to load the module, and then require it. Both of these methods are annoying and are incredibly dumb workarounds.
5 Likes
This is very annoying when testing if I have multiple requires to external modules. Will there be a feature to turn it off. Iâm almost never using free models and when I am itâs well known ones like HD admin commands and that isnât a virus. I also have plugins such as In-Command that I had to disable because it required an external module and the output was very destracting
7 Likes
Of course, I knew it as well. Thats enough internet for me lmao.
2 Likes
No, because then it would say - <some script> instead of - Studio.
2 Likes