FernandoMTA Posted February 17, 2023 Share Posted February 17, 2023 (edited) Let's talk script security. It might be a taboo topic for some but it shouldn't, at all. In fact, the more people talk about this and unite to discuss and create robust, safe and well-coded scripts, the better the MTA resource development community will be. Rules: Spoiler Don't use this thread to just complain about X script or Y server being unsafe or having bad scripts made by people with little skill. MTA scripting is not something you master by just mastering the Lua programming language. You need to understand how the MTA ecosystem works and how everything functions. It's pointless to make fun of people who are doing things incorrectly. MTA has a powerful anticheat that saves us developers a lot of trouble. But this never meant that you can create scripts with 0 care and regard for security and just assume that the AC will catch players abusing your systems and exploiting your server with their client. Please respect the AC team that are not here to fulfill your needs as a developer. They are here to assure platform security, you are responsible for the resources you make. Use this thread to talk about script security, anti-cheating and preventing abuse. The goal is to have a space where people can post their creations and share thoughts, which will be pinned on this main post. General tips for newbies regarding server setup and resources in general are welcome. Main article: https://wiki.multitheftauto.com/wiki/Script_security The key points are there, but the code examples don't suffice, and the implementations will vary depending on the gamemode and resources. Pinned information: Coming soon Notes: - I'm not perfect and everyone makes mistakes. Please correct me when I'm wrong. - Eventually if this becomes a popular topic, I am willing to incorporate translations of certain explanations into other languages in this OP, as I know a majority of the MTA community doesn't master the English language and prefers to communicate and read in other languages. Edited February 20, 2023 by FernandoMTA Link to comment
Shady1 Posted February 17, 2023 Share Posted February 17, 2023 (edited) i always prefer to use server-side if i want to make a secure script Edited February 17, 2023 by Shady1 Link to comment
FernandoMTA Posted February 17, 2023 Author Share Posted February 17, 2023 (edited) Facts: a large amount of MTA "RP" servers of various languages are using the OwlGaming Gamemode as a base because of its features and "ease of use". Even before 2020 when it was released, using the leaked 2015 oG version... The repository seems to have been abandoned by its creators who are not responding to any further Issues/PRs. It's demotivating for people who might've wanted to contribute to it eventually. Cons: excessive use of element data, optimization concerns (just use IPB to analyse the default oG resources), many minor and major script security issues. I could name them, and I'm not the only one who'd be able to talk for countless hours about this gamemode. Large gamemodes, especially ones that are several years old (OwlGaming GM now has code that is 10+ years old!) don't usually age well with time, and need regular updates (which hasn't happened with this case). What can be done? Someone makes a fork of that codebase and fixes the issues, improving the GM in general. Then we share this project on the Forums etc so it gets enough attention. Why do this? Well, saves people money and time. Why pay a developer to fix specific issues of a public codebase for your server specifically when community effort can do it publicly and everyone benefits from the changes. Seriously, I've seen way too many people suffer with scripts revolving around the OwlGaming/vG ecosystem that we would all benefit from having an updated version of it or something equivalent that is free for everyone to use. Sure, there are some very few quality RP gamemodes out there for sale, but we know that everyone seeks the cheapest option. Owl wasn't a one-man job, and it's not easy to remake a roleplay gamemode from scratch (as proven many times already). The fact that it's the most popular open source alternative makes it important that we address its usage in 2023. Edited February 17, 2023 by FernandoMTA Link to comment
Mittell Buurman Posted February 17, 2023 Share Posted February 17, 2023 I have been working on building a new RP gamemode for this reason. With about 10 years of work, it has been handed from one community to another, passed by various developers and script kiddies alike. It was a project where we used our limited knowledge and what we found to be ‘best practises’. And with the current RP eco system, It has run stale. It is not just about the gamemode itself, but the sheer amount of communities making their effort to ‘be the next RP server’. Yet is has proven difficult to gain and maintain a solid playerbase, if it is the same refurbished gamemode all over again. as mentioned before. I’ve already started with creating a new RP framework, which is a hefty operation. if the community still has an interest in a roleplay gamemode. I don’t think using, or even refactoring OG resources will cut the deal. It has been a passion project with 10 years of work, where there has been little oversight on the overall quality. It is better to use it as a reference sheet than anything else. 1 Link to comment
FernandoMTA Posted February 17, 2023 Author Share Posted February 17, 2023 (edited) 11 minutes ago, Mittell Buurman said: I have been working on building a new RP gamemode for this reason. With about 10 years of work, it has been handed from one community to another, passed by various developers and script kiddies alike. It was a project where we used our limited knowledge and what we found to be ‘best practises’. And with the current RP eco system, It has run stale. It is not just about the gamemode itself, but the sheer amount of communities making their effort to ‘be the next RP server’. Yet is has proven difficult to gain and maintain a solid playerbase, if it is the same refurbished gamemode all over again. as mentioned before. I’ve already started with creating a new RP framework, which is a hefty operation. if the community still has an interest in a roleplay gamemode. I don’t think using, or even refactoring OG resources will cut the deal. It has been a passion project with 10 years of work, where there has been little oversight on the overall quality. It is better to use it as a reference sheet than anything else. I admire your efforts to create a new RP gamemode . It's definitely the solution. Refactoring the OwlGaming gamemode is painful and it'll never achieve perfection, but I've seen from experience that it's possible to at least address the biggest performance issues and drastically reduce memory usage of its resources, so people already using it could update it... while no better known alternative exists. Edited February 17, 2023 by FernandoMTA Link to comment
Moderators IIYAMA Posted February 18, 2023 Moderators Share Posted February 18, 2023 Just a note. Instead of doing a source validation. -- The source for this event is always 'resourceRoot' if source ~= resourceRoot then reportNaughtyness( eventName, client, "source" ) return end You can also disable propagate: addEvent("onRaiseTheRoof", true) addEventHandler("onRaiseTheRoof", resourceRoot, function(arg1, arg2) end, false -- < disable propagate ) While it does not report naughtiness, it is very easy to add. 2 Link to comment
Tekken Posted February 18, 2023 Share Posted February 18, 2023 Also always use client variable server-side instead of source and/or passing the localPlayer as an argument when referring to the player that triggered a server event. 2 Link to comment
Mittell Buurman Posted February 18, 2023 Share Posted February 18, 2023 Also, in terms of using `addeventHandler` on `getRootElement()` should also be limited. If you're using pickup, collisions, markers, or really any other element that does not require inheritance from a specific event handler. it is best to bind them strictly to the specific element itself. Link to comment
FernandoMTA Posted February 20, 2023 Author Share Posted February 20, 2023 On 18/02/2023 at 14:50, Mittell Buurman said: Also, in terms of using `addeventHandler` on `getRootElement()` should also be limited. If you're using pickup, collisions, markers, or really any other element that does not require inheritance from a specific event handler. it is best to bind them strictly to the specific element itself. Yes, or addEventHandler to a group of elements. Link to comment
Recommended Posts