NanoBob

What you describe does not sound like a perfect solution to authentication, especially in regards to serial spoofing, and serials not being guaranteed to be unique. All you would need to know regarding safe authentication and handling of credentials can be found here: disclaimer: I'm the author of the user guide in question.

That is true, the current Slipe (which we call "Slipe Lua") translates the C# code to Lua before running it. But this still gives you plenty of benefits. We are however also working on a way to run native C# code on an MTA Server, which we are doing by creating the MTA server itself from scratch.

As one of the developers behind SAES:RPG, the server in question appears to not use any leaked scripts from SAES:RPG (I did a brief check). And it's not like SAES has patented / has a trademark on the idea of our gamemode, so anyone is free to make a gamemode in the same general spirit / idea. With that said, I wish you guys the best of luck.

Lua tutorial for absolute beginners This tutorial can also be viewed on GitHub This tutorial aims to teach the Lua scripting language to those with 0 previous experience with programming / scripting. This guide will start with explaining some Lua concepts, and will later on move to explaining MTA:SA specific concepts. Table of contents: Lua Scripts Variables Data types Operators If statements Functions Return values scopes & locals For loops Tables Iterators (pairs/ipairs) Callbacks Anonymous functions MTA Server & Resources Server vs client MTA functions & wiki Elements (userdata) Command handlers Event handlers predefined globals server <-> client communication Now what? Lua This part of the tutorial discusses Lua itself. No MTA-specific concepts will be discussed here. Scripts The Lua scripting language is a language which is interpreted by a "Lua interpreter". MTA:SA's resources use such an interpreter to run Lua code. For the beginning of this tutorial you can use the online Lua interpreter available on https://www.Lua.org/demo.html. Any code in the Lua part of the tutorial can be run on this website. Lua is written in "plain text". This means it exists of regular characters like any other text you are writing. To edit Lua files you will require a text editor. You could use Notepad, but there are many far better alternatives. My personal favourite is Visual Studio Code, but there are many other good options, to name a few: Atom, sublime text, notepad++ Lua files are usually saved with the .Lua file extension Variables The first concept we're going to discuss is variables. Variables allow you to store a value in your code. For example: x = 10 print(x) print(x) will output the value of the x variable. We will get into what exactly print is later in the tutorial. Variables can have any name you want, as long as you follow some specific rules. variable names must start with a letter (lower or upper case), or an underscore (_) variable names may contain letters (lower and upper case), numbers and underscores. x = 10 y = 20 z = 30 print(x) print(y) print(z) The convention in Lua is to name your variables in "camelCase". This means if a variable exists of multiple words you start every word with a capital letter, except for the first one. camelCaseVariable = 5 Data types So far we've seen variables used to store numeric values, but there are many different types of data Lua can handle. These are: number Any numeric value string A piece of text, a string is surrounded by " or '. For example "Hello world" or 'Hello world' boolean A boolean is a data type that has only 2 options, true and false. nil nil is a value indicating nothing. It's the absence of a value. (Not the be confused with 0) table Tables will be discussed later in the tutorial userdata Userdata will be discussed later in the tutorial function Functions will be discussed later in the tutorial thread Threads are out of scope for this tutorial and won't be discussed So we can use these different data types, and store them in variables: numberVariable = 10 stringVariable = "Hello world" booleanVariable = true nilVariable = nil Operators Operators are symbols in Lua which can be used to do "things" with variables. Here's a list of operators and an example for each: + operator Adds two values together x = 10 + 10 print(x) y = 20 print(y) z = x + y print(z) - operator Subtracts a value from another value x = 10 - 10 print(x) * operator Multiplies two values x = 10 * 10 print(x) / operator Divides a value by another value x = 10 / 10 print(x) % operator This is the "modulo" operator. This will divide a value by another, and return the leftover. x = 10 % 4 print(x) The result of this is 2 and operator The and operator will return true if both variables are "truthy". Otherwise it returns false (A "truthy" value is anything except for false and nil) x = true and false print(x) y = true and true print(y) or operator The and operator will return true if one of the variables are "truthy". Otherwise it returns false x = true or false print(x) y = false or false print(y) == operator The == (equals) operator will return true if both of the variables are the same. Otherwise it returns false x = "hey there" == "hello there" print(x) y = 150 == 150 print(y) ~= operator The ~= (does not equal) operator will return true if both variables are not the same. Otherwise it returns false x = "hey there" ~= "hello there" print(x) y = 150 ~= 150 print(y) > operator The > (greater than) operator will return true if the first value is greater than the second value. Otherwise it returns false x = 10 > 5 print(x) y = 10 > 15 print(y) y = 10 > 10 print(y) >= operator The >= (greater than or equals) operator will return true if the first value is greater than, or equal to, the second value. Otherwise it returns false x = 10 > 5 print(x) y = 10 > 15 print(y) y = 10 > 10 print(y) < operator The < (less than) operator will return true if the first value is less than the second value. Otherwise it returns false x = 10 < 5 print(x) y = 10 < 15 print(y) y = 10 < 10 print(y) <= operator The <= (less than or equals) operator will return true if the first value is less than, or equal to, the second value. Otherwise it returns false x = 10 < 5 print(x) y = 10 < 15 print(y) y = 10 < 10 print(y) .. operator The .. (string concatanation) operator allows you to add two strings together. x = "Hello" z = "World!" combined = x .. " " .. z print(combined) If statements An if statement allows your code to decide to do something, or not. Depending on a value. Often times if statements are used in combination with some of the above operators. An if statement is written as : if <expression> then <code> end x = 10 if x > 5 then print("X is higher than 5") end Any code between then and end will only be executed when the expression is true. You might also have noticed that the code between the then and end is moved over a bit to the right. This is called "indentation". Whenever we open a new scope (scopes will be discussed later in the tutorial) we move our code to the right. This is usually done by either a tab or several spaces . Many code editors will convert a tab to spaces. Else Within an if statement, you can also add an else block. The code in such a block will be executed when the code in the if block is not executed. x = 10 if x > 5 then print("X is higher than 5") else print("X is not higher than 5") end Elseif If you want to do multiple if statements, you can use an elseif: x = 15 if x > 10 then print("X is higher than 10") end if x > 5 then print("X is higher than 5") end x = 15 if x > 10 then print("X is higher than 10") elseif x > 5 then print("X is higher than 5") end The difference between the first example and the second is that if x is higher than 10 in the first example both lines "X is higher than 10" and "X is higher than 5" will be output. Whilst in the second example only "X is higher than 10" will be output. And if statement must always start with an if, can contain multiple elseifs, and may only have one else. name = "NanoBob" if name == "NanoBob" then print("Hello world!") elseif name == "Brophy" then print("Black 123") elseif name == "Tombaa" then print("Stupid") else print("I have no idea") end Functions Functions allow you to write less code, by reusing pieces of code. The syntax to create a function is function <name>(<parameters>) <code> end function foo() print("Hello world #1") print("Hello world #2") end In order to execute code in the function, you "call" the function. You do this by writing the function name followed by (). function foo() print("Hello world #1") print("Hello world #2") end foo() foo() foo() Functions also allow you to send a variable to the function, for it to do something with. This is what's called a function parameter. Function parameters are defined in the brackets () after the function name. function foo(x) print(x) end foo(10) foo("50") You may notice that this looks a lot like the print() we have been using. This is because print is a built-in Lua function. Return values A function not only can execute code, it can also give something back to where it was called. This is called a return value. In order to return something from a function you use the return keyword. function foo() return 10 end x = foo() print(x) print(foo()) Just like in an if statement, all code within a function is indented. Now let's combine everything we have learnt so far: function foo(x) if x > 10 then return "X is higher than 10" elseif x > 5 then return "X is higher than 5" else return "X is not higher than 5" end end y = foo(15) print(y) print(foo(10)) print(foo(0)) Scopes & locals We quickly encountered scopes before, and said we indent our code whenever we enter a new scope. But scopes allow you to do more than that. Most importantly, "local" variables. A local variable is only available in the scope it was defined in (or scopes that were created from within that scope) You can create a new scope using a do block (functions and if statements also have their own scope). do local x = 5 print(x) end print(x) do local x = 5 do local y = 10 print(x) print(y) end print(y) end For loops (For) loops are ways in scripting / programming to have code executed multiple times, without having to write the same thing multiple times. An example of such a loop: for i = 1, 10 do print(i) end The first part : i = 1, 10 defines a variable called i. Which start at 1. This will be incremented by 1, until it reaches 10. The code within the loop then can use this variable. You can also increment with a different number than 1 (including negative numbers) using this construct. for i = 20, 0, -2 do print(i) end This code sample will start with i at 20, and keep adding -2 (thus subtracting 2), until it reaches 0 Tables Tables are a datatype in Lua which allows for lists of things. Here's an example: x = { [1] = 100, [2] = 200, [3] = 300 } print(x[1]) print(x[2]) print(x[3]) Tables consist of key/value pairs. In the example above the key 1, has the value 100, 2 has the value 200, and 3 has the value 300. You can get the value in a table, by putting the key in between square brackets []. Like in print(x[1]). x = { 100, 200, 300 } print(x[1]) print(x[2]) print(x[3]) You can choose to not include the keys in a table. Doing so will automatically add numbers as keys, starting at 1. So the above example would be the exact same as the first example. Table keys and values can be of any data type, including other tables. This allows you to create (very) complex table structures. t = { [1] = { 100, 200, 300 }, ["x"] = 100, [true] = "something" } print(t["x"]) print(t[true]) print(t[1][1]) print(t[1][2]) print(t[1][3]) When using a string as the key in a table, you can leave out the square brackets and the quotes. This goes for both when defining the table, and for indexing it (getting a value from it). For example t = { x = 100, y = 200, z = 300 } print(t.x) print(t.y) print(t.z) A table's values can be modified / set after creating the table as well. t = {} t[1] = 10 t[2] = 20 t[3] = 30 t["x"] = "banana" t[true] = false t.x = "banana" When using tables you will often want to add something to the "end" of a table. This is most common when you are using tables with numeric keys. In order to do this you can use a # to get the amount of items currently in the table. t = { 10, 20, 30 } t[#t + 1] = 40 This will store the value 40 on the key 4 , because #t is 3. Iterators (pairs/ipairs) Iterators are a mechanism that allow you to make a loop, which goes over a set of values. Writing your own iterators won't be discussed in this tutorial. But there are two functions which are often used to create an iterator to iterate over a table. These are pairs and ipairs. t = { 10, 20, 30, 40, 50 } for key, value in ipairs(t) do print(key, value) end The difference between pairs and ipairs is the order in which the key/value pairs are iterated over, and which of the key/value pairs are iterated over. Where ipairs will always use numeric keys, starting at 1, and going up by 1 every time, until there is no entry in the table. This also means it won't iterate over anything key that is not numeric. t = { ["x"] = 5, [1] = 10, [2] = 20, [3] = 30, [5] = 50, } for key, value in ipairs(t) do print(key, value) end A pairs loop will iterate over any value in a table, but the order is not guaranteed. Meaning that between different runs of the script the order could be different. t = { ["x"] = 5, [1] = 10, [2] = 20, [3] = 30, [5] = 50, } for key, value in pairs(t) do print(key, value) end Callbacks Callbacks are when you pass a function as an argument to another function. To have the function you passed be called later on. This is used often within MTA. An example of a Lua function which uses a callback is table.sort. table.sort will sort a tables values, by default these values are sorted numerically. But you can use a callback to change this behaviour. values = { 5, 4, 3, 6, 8, 1, 2, 9, 7 } function sortFunction(a, b) return b > a end function reverseSortFunction(a, b) return a > b end table.sort(values, sortFunction) print("Sorted: ") for _, v in ipairs(values) do print(v) end table.sort(values, reverseSortFunction) print("\nReverse sorted: ") for _, v in ipairs(values) do print(v) end In the first call to table.sort (table.sort(values, sortFunction)) you can see the sortFunction function is passed as second argument to the function. Note that we don't write sortFunction() here (notice the brackets difference) because that would call the sortFunction function, and pass its return value to table.sort. table.sort will then call this function when it compares two different values, this function should return true or false depending on whether its second argument (b in this case) is larger than it's first argument (a), in the context of sorting. Anonymous functions It is also possible to use an "anonymous function" when passing a callback to a function. values = { 5, 4, 3, 6, 8, 1, 2, 9, 7 } table.sort(values, function(a, b) return b > a end) print("Sorted: ") for _, v in ipairs(values) do print(v) end table.sort(values, function(a, b) return a > b end) print("\nReverse sorted: ") for _, v in ipairs(values) do print(v) end MTA This part of the tutorial discusses MTA specific constructs. Code in this part of the tutorial won't run in the online Lua interpreter. You will need to set up a (local) server for this. Server & Resources By default when installing MTA:SA a server is installed as well. This server is located in the "server" directory of your MTA directory. This is usually at C:\Program Files (x86)\MTA San Andreas 1.5\server. This directory contains an MTA server.exe file, running this file will start a server. Scripts on a server are grouped by resources, a single resource can consist of multiple script files and other assets such as images, sounds, fonts, mods and more. Resources are placed in your mods\deathmatch\resources folder in your server folder. A resource is always in its own directory. A resource must always have a single meta.xml file. This file tells the server (among others) what script files to load. A typical meta.xml file looks like this: <meta> <script src="vehicleSystem.Lua" type="server"/> <script src="vehicleMods.Lua" type="client"/> </meta> You will need an entry for every .Lua file you want to have executed on the server. You can start a resource by typing start <resource name> in the server console (the window that opened when you started MTA Server.exe). The resource name is the name of the directory your meta.xml is in. (This may not have spaces). Starting a resource will start running the Lua scripts, if you've changed your scripts you will need to restart the resource for the changes to take effect. (restart <resource name>). Server vs client Lua code can be executed in one of two places. The server, or the client. Server sided scripts are executed on the actual machine that is running the MTA server.exe process. Client sided scripts are executed on the computer of every player that connects to your server. Server sided and client sided scripts have a distinct difference in responsibility and possibility. Some functions for example are only available on the client, whilst others are available only on the server (and many on both). Note: Some of these functions which are available both server sided and client sided are different on server and client MTA functions & wiki In plain Lua there's not much you can do to affect a game engine like MTA:SA. This is why MTA:SA offers a (large) list of functions available for you to use in your scripts which interact with the actual GTA world. You can find a list of all of these, what they do and how to use them on the MTA wiki. Server sided functions Client sided functions shared functions An example of such a function is createObject(). This function will create a physical object in the game. The wiki page contains information on how to use it (what arguments it expects, and in what order). And often shows an example of how to use it. createObject(1337, 0, 0, 3) Elements (userdata) At the start of this tutorial we quickly mentioned userdata data types. These are data types configurable by the implementation of Lua. In this case, MTA. MTA uses userdata to represent "elements". Many things in MTA are elements, like objects, markers, peds, players, user interfaces, vehicles, etc. On the MTA wiki you will notice many functions either return elements, or require an element as arguments. A list of different types of elements can be found on the MTA wiki. Elements also have a hierarchical structure to them. Elements can have a "parent", and multiple "children". This will result in a tree of elements, the element at the top of this tree (and thus the grandparent of all elements) is called the root element. Command handlers Often times in MTA you want certain things to happen when a player enters a command. This is done using command handlers, command handlers use a callback, which we previously discussed. The wiki contains a page for the addCommandHandler() function. For this example we will be using the server side version. function handler(player, command, argument) outputChatBox("You entered " .. command) if argument ~= nil then outputChatBox("You used the argument " .. argument, player) end end addCommandHandler("banana", handler) This example also uses the outputChatBox() function, this will output a piece of text to the chat.(in this case, only for the player who executed the command) The callback function passed to addCommandHandler will be called every time a player uses the /banana command ingame. Event handlers Besides having your script do things when a user executes a command you likely want the game to respond to many different types of things that happen in the game. Like players taking damage, coming close to something, etc. These things are called events. Whenever an event is triggered you can run a piece of Lua code. You do this using event handlers. Event handlers are created using the addEventHandler(). The first argument to the addEventHandler() function is the string name of the event. These can be found on the MTA wiki as well. Server sided events Client sided events An event is always triggered for a specific element, for example "onPlayerWasted" is triggered on the player that was wasted (killed). You can attach an event handler to a single element to only have your callback function be called when the event is triggered on that specific element. But you could also use the root element here and your function will be called for every element the event is triggered on. function handlePlayerDeath() outputChatBox("You died!!", source) end addEventHandler("onPlayerWasted", getRootElement(), handlePlayerDeath) The getRootElement() function used in this example returns the root element discussed earlier. You can also see source is used in this code snippet, we'll talk about that some more in the next section. predefined globals MTA has some predifined global variables for you to use in your script. A list of them can be found on the wiki. Here's a couple notable ones and what they're used for root The root element, same as the return value of getRootElement()) source The element an event handler was called on. An event's wiki page always describes what the event source will be for the event. localPlayer The player element for the player whose client the script is running on. (Thus only available client sided) client Will be discussed in the next section server <-> client communication As stated earlier in this tutorial scripts can run either on the server, or one of the connected clients. However often times you would want to trigger something on the server from a client, or the other way around. An example of this would be when the user clicks the login button on a GUI (Graphical user interface) the server should try to log that person in, and send him back whether or not this was successful. This can be done using events. MTA allows you to create and trigger your own events, and these events can be triggered from server to client (and the other way around). You can do this using the addEvent() function. Once an event has been added (and marked as remotely triggerable by passing true as second argument to addEvent()) you can call it from server/client. You do this using [triggerClientEvent()]https://wiki.multitheftauto.com/wiki/TriggerClientEvent() and triggerServerEvent() respectively. Server sided: function handlePlayerLogin(username, password) outputChatBox("You tried to log in with the username " .. username, client) end addEvent("LuaTutorial.Login", true) addEventHandler("LuaTutorial.Login", root, handlePlayerLogin) Client sided: function pretendLogin() triggerServerEvent("LuaTutorial.Login", localPlayer, "username", "password") end pretendLogin() This example will trigger the "LuaTutorial.Login" event from the client sided script. And passes the "username" and "password" arguments to the event. The server then handles this event in the handlePlayerLogin() function, which in our case just outputs something to the chatbox. In this example you can see the previously mentioned client global variable. This variable is set to the player element corresponding to the client the event was triggered from. (And is thus only usable when used in an event handler which has been triggered from a client). Now what? With this information you should be able to start scripting, and making things in MTA! If you didn't understand it all in one go, or you have any more questions there is no shame in that! You can find myself and many others willing to help you with your scripting questions in the #scripting channel on the MTA discord. Another good source for programming / scripting related questions is stack overflow.

A new version of the core has been released! Async RPCs A new feature called "Async RPCs" has been implemented. This allows you to return a value over an RPC, and use `async / await` in order to use it, so you will no longer need to bounce RPCs back and forth to get a value from the server to the client or vice versa. Example: Server: RpcManager.Instance.RegisterAsyncRPC<SingleCastRpc<string>, EmptyRpc>("Async.RequestMapName", (player, request) => { return new SingleCastRpc<string>(GameServer.Announcement.MapName); }); Client: Task.Run(async () => { string name = (await RpcManager.Instance.TriggerAsyncRpc<SingleCastRpc<string>>("Async.RequestMapName", new EmptyRpc())).Value; ChatBox.WriteLine($"Map name: {name}"); }); Updating In order to update an existing project use `slipe update-core`

A new version of the CLI and core have been released! RPC bug An issue has been fixed with RPCs, RPCs now work as expected when registering multiple handlers to the same RPC key Update to dotnet core 3! Slipe now runs on non preview versions dotnet core 3, this means you no longer need to use visual studio 2019 preview (use the regular 2019 version, make sure to update it to the latest). And you will no longer need to specify the use of experimental frameworks. Updating In order to update your CLI run `slipe update` In order to update an existing project use `slipe update-core`

A new version of the CLI and core have been released! RPCs RPCs being split up into two seperate classes was a bit unintuitive. So we've combined them into a single class. More information on how RPCs work now on https://mta-slipe.com/docs/rpc.html Slipe WPF We've released our first "first party module". Slipe WPF! Slipe WPF allows you to create Windows Presentation Foundation (WPF) user interfaces in Visual studio, and then run these in MTA. Warning Slipe WPF is even more alpha than Slipe itself. So no guarantees that it will be bug free. Information on setting up WPF can be found on: https://github.com/mta-slipe/Slipe-wpf A sample resource using WPF can be found on: https://github.com/mta-slipe/Slipe-login Updating In order to update your CLI run `slipe update` In order to update an existing project use `slipe update-core`

A new version of the CLI and core have been released! Updating from dev Since Slipe is still in development and we can't always make releases to hotfix an issue we've added the ability to update your CLI and project to the current development branch of the repo. What this means is you will be running the latest version, however these versions are more prone to bugs / unfinished features. In order to update the CLI from the development branch use: `slipe update -dev` In order to update a project from the development branch use: `slipe update-core -dev` Element data sigh, we've implemented element data. We still recommend people don't use it if you can. The only reason we implemented it is to support compatibility with non-slipe resources or mapping files. Bugs We've fixed several bugs, including some important ones related to events. Updating In order to update your CLI run `slipe update` In order to update an existing project use `slipe update-core` Also, update your .net core 3.0 to the most recent preview (preview 7)

Introduction Properly handling your user's credentials (username and password) is very important, this guide gives detailed information and code samples on how to (properly) implement an account "system". This guide assumes you are not using MTA's built in accounts. Disclaimer: Any code shown in this tutorial is purely for illustrative purposes, and is not finished code, you should use it as a guideline, not a solution. Content The following topics will be discussed in this tutorial: How to hash and salt passwords (register) How to validate a hashed password (login) How to add "remember-me" functionality How to offer password recovery How to migrate from an older hashing algorithm, to a newer one Using a password policy (Extra) How to handle database leaks (Extra) What even is hashing and salting? For the purpose of this tutorial we expect a database structure which is somewhat similar to this: How to hash and salt passwords When you have a user register on your service, that user expects of you to keep their password safe. Whilst it is generally bad practice to use the same password for multiple services there are many users that still do so. Because of this it's crucial that you save the user's passwords in a way that an attacker will be unable to find out the original password the user typed. This includes if they have full access to your database. In order to do this we do what is called "Password hashing" When a user registers, your server receives the user's intended username, (email) and password. Before you save that password to the database you have to hash and salt this, luckily MTA has a function that takes care of this. If you wish to know more about what exactly it does, there's more information at the end of this tutorial. In order to hash this password you use the passwordHash function. This function is relatively slow (by design), so it is highly recommended you pass a callback to this function, so your entire script doesn't wait for it to complete. https://wiki.multitheftauto.com/wiki/PasswordHash local mysqlHandle -- we're assuming this value is set somewhere else in code function register(username, email, password) local player = client passwordHash(password, "bcrypt", {}, function(hashedPassword) -- callback function for hashing the password local handle = dbQuery(function(handle) -- callback function for storing the user in the database if (handle) then triggerClientEvent(player, "registrationSuccess") -- inform the user that registration was successful else triggerClientEvent(player, "registrationFailed") end end,mysqlHandle, "INSERT INTO users (email, username, password) VALUES (?, ?, ?)", email, username, hashedPassword) end) end addEvent("passwordTutorial:register", true) addEventHandler("passwordTutorial:register", getRootElement(), register) How to validate a hashed password Once you've saved the hashed password to your database you need to do a little bit of additional work when authenticating the user. Luckily MTA offers a passwordVerify() function, which is the counterpart of the previously discussed passwordHash(). What this function does it basically hashes the password in the same way, resulting in the same output hash. https://wiki.multitheftauto.com/wiki/passwordVerify In order to get the account the user is trying to log in to you have to do a query for an account which has the user submitted username, and of which the password matches through passwordVerify. PasswordVerify is also a relatively slow function, thus you should use a callback. function login(username, password) local player = client dbQuery(function (handle) -- callback for the query selecting the user by username local results = dbPoll(handle, -1) if (#results == 0) then triggerClientEvent(player, "loginFailed") return end passwordVerify(password, results[1].password, {}, function(matches) -- callback function for the password verify if (matches) then -- Do anything you wish with the database result to log the player in with the rest of your scripts triggerClientEvent(player, "loginSuccess") else triggerClientEvent(player, "loginFailed") end end) end, mysqlHandle, "SELECT * FROM users WHERE username = ?", username) end addEvent("passwordTutorial:login", true) addEventHandler("passwordTutorial:login", getRootElement(), login) How to add "remember me" functionality When users on your server log in, they often do not want to have to enter their username and password every time they want to log in. In order to satisfy this need you can implement a "remember me" function. What I've seen happen in the past, is people would store the user's password (encrypted) on the client. This is NOT safe, and should never be done! In order to properly use remember me functionality what you would do is upon login in, generate a random string. The longer the better. This random string is what we call an access token. You would then allow the user to log in with such an access token, preferably only once generating a new access token each time one is used. To implement this you would generate that token every time the user logs in, whilst they have "remember me" enabled. You will have to save this token in your database alongside your user. For extra security you could also store the user's serial alongside the access token, you can then validate that the access token is being used from the same device. https://wiki.multitheftauto.com/wiki/Filepath function login(username, password) -- This code should be put in the callback to the dbQuery function, but to keep the example clean that's not shown here if (rememberMe) then local token = generateRandomToken() dbQuery(mysqlHandle, "INSERT INTO access_tokens (user_id, token) VALUES (?, ?)", results[1].id, token) triggerClientEvent(player, "loginSuccess", token) end end function rememberMeLogin(username, accessToken) -- this function handles a user's login attempt dbQuery(function(handle) local result = dbPoll(handle, -1) if (#result == 0) then triggerClientEvent(player, "loginFailed") else -- Do anything you wish with the database result to log the player in with the rest of your scripts triggerClientEvent(player, "loginSuccess") end end,mysqlHandle, "SELECT users.* FROM access_tokens JOIN users ON users.id = access_tokens.user_id WHERE users.username = ?", username) end addEvent("passwordTutorial:loginRememberMe", true) addEventHandler("passwordTutorial:loginRememberMe", getRootElement(), login) How to offer password recovery Offering password recovery requires a little bit more than just your MTA server. Generally password recovery is done with emails. So you would need access to an email server / service which you can use to send an email from an HTTP request. (Like you can do with fetchRemote()). When a user requests a password reset, have them enter the email you registered with. You then fetch a user from the database with this email address. You would then store a password recovery token for this user. This token, just like the remember me token, is a random string. Ideally, you would send the user a link with a password reset form that goes to a webpage where the user can reset their password. You could do this with an external service, like a webserver. Or you could use MTA's Resource web access for it, but if you do make sure you handle permissions properly for anything else that uses this. However another option would be to have the user copy paste the generated token from the email into you server's login window. Which of the two solutions you pick is up to you, my personal preference goes to the one with the link in the email. But in either case the server side logic is the same. When the user attempts to perform password recovery, verify that the token they give you belongs to a user, and then change the password to the newly requested password. Make sure you hash this password the same way you do in your login. function requestPasswordRecovery(email) dbQuery(function (handle)) local result = dbPoll(handle, -1) if (#result == 0) then triggerClientEvent(player, "passwordTutorial:passwordRecoveryRequestFailed") else local token = generateRandomToken() dbExec(mysqlHandle, "UPDATE user_data SET recovery_token = ?", token) -- mail the token to the user, mail implementation depends on the mail server/service you use triggerClientEvent(player, "passwordTutorial:passwordRecoveryRequestSuccess") end end, mysqlHandle, "SELECT * FROM users WHERE email = ?", email) end function recoverPassword(recoveryToken, password) dbQuery(function (handle) local result = dbPoll(handle, -1) if (#result == 0) then -- this is only valid if you have the user request password recovery from ingame triggerClientEvent(player, "passwordTutorial:passwordRecoveryFailed") else passwordHash(password, "bcrypt", {}, function(hashedPassword) -- callback function for hashing the password local handle = dbExec(function(handle) -- callback function for storing the new password in the database if (handle) then -- this is only valid if you have the user request password recovery from ingame triggerClientEvent(player, "passwordTutorial:passwordRecoverySuccess") -- inform the user that registration was successful else -- this is only valid if you have the user request password recovery from ingame triggerClientEvent(player, "passwordTutorial:passwordRecoveryFailed") end end,mysqlHandle, "UPDATE user_data SET password = ? WHERE recovery_token = ?", username, recoveryToken) end) end end, "SELECT * FROM users WHERE recovery_token = ?", recoveryToken) end Besides changing the password, it's important you also delete any access tokens that user might have if you're using remember me functionality. It is also good practice to make recovery tokens expiry after a certain amount of times, and not allow a recovery token to be created whilst one is already in progress. This prevents a user from sending a large number of emails from your service. How to migrate from an older hashing algorithm, to a newer one Maybe after reading this topic you realise that your password security is not what it should be. So you want to change your old password hashing / validation logic to the ones explained in this topic. And due to the nature that hashes can not be "unhashed", you can't simply migrate your passwords over. So in order to migrate the passwords what you have to do is when a user logs in, first validate their password with the old hashing algorithm. If this matches, then hash (and salt) it with your new hashing algorithm and save it in your database. Make sure to delete the old password otherwise your password security is not any better than before. Using a password policy Passwords policies are important to prevent your users from picking a password that is too easily cracked / brute forced. Many password policies come in the form of "Must have at least one capital letter, one digit and one number". But that discards that fact that the best way to make your password more difficult to crack, is making your password longer. So in the code snippet below is a function that measures the 'search space' of a password. The search space of a password is the amount of possible passwords there are with a certain combination of characters. In order to use this, you would have to set a minimum password search space when a user registers for an account. This minimum is up for you to set, but be reasonable, you shouldn't expect a user's password to be impossible to remember / create. I recommend playing with the function a bit to see what values you get out of it, and pick something you believe is sensible. function getPasswordSearchSpace(password) local lowerCase = password:find("%l") and 26 or 0 local upperCase = password:find("%u") and 26 or 0 local digits = password:find("%d") and 10 or 0 local symbols = password:find("%W") and 32 or 0 local length = password:len() return (lowerCase + upperCase + digits + symbols) ^ length end -- The below function calls are to indicate the difference in search space for a set of passwords print(getPasswordSearchSpace("a")) print(getPasswordSearchSpace("abc")) print(getPasswordSearchSpace("Abc")) print(getPasswordSearchSpace("Ab!")) print(getPasswordSearchSpace("Ab!0")) print(getPasswordSearchSpace("Mu#9A0h.")) print(getPasswordSearchSpace("This is a demonstration of how easy an incredibly strong password is to remember")) How to handle database leaks If you have reason to believe that your database has been leaked or otherwise compromised, it is important that your first course of action is removing any access tokens stored in your database. Once you have done that you have to inform your users. Whilst when properly hashed and salted it's extremely difficult / time consuming to find out a user's password it is still a possibility. So you should inform your users of the breach, tell them that their passwords were properly hashed, and they do not need to fear for their passwords immediately. However you should suggest to your users that they change their password either way, just in case. What even is hashing and salting? Hashing has been brought up several times in this tutorial, whilst you do not need to know what it is / does, you might be interested in knowing regardless. I won't be going too far in depth as I simply do not have the knowledge, but the basic idea of hashing is this: When you hash anything, you turn it into a string of characters (or other value) that has no relation to the original input, other than when you hash the original input again, it will always generate the same hash. For example, when you hash the string 'banana' using the sha512 hashing algorithm, it will always yield the output: "F8E3183D38E6C51889582CB260AB825252F395B4AC8FB0E6B13E9A71F7C10A80D5301E4A949F2783CB0C20205F1D850F87045F4420AD2271C8FD5F0CD8944BE3" Now hashing can not be reverted, you can not "unhash" a hash, so in order to verify someone's password you hash it again, and see if the two hashes are the exact same. Now this is great, passwords are safely stored. However there is still more to do, salting. Salting is adding some random data to your password prior to hashing it. This prevents when two users (on the same service, or on others) have the same password, that their hashes are also the same. Meaning if one password is compromised, the other password is not. It is important that a salt is random for every user in your application, not one salt for your entire application. Now you might think we didn't do any salting in the code / tutorial above. This is not true, we just didn't do it ourselves. MTA's passwordHash function actually hashes the passwords and salts it, this salt is then stored in the output hash it self, just before the actual password hash. In the case of bcrypt it actually stores a little bit more info in the resulting hash, but you need not worry about that.

That would also be rather insecure Soapbosnia, as you would be storing it in recoverable form on the client. (Aka plaintext or encrypted). So all someone would need to do is access the file in order to gain access to the password. When using a token even if that token is compromised the actual password is still secure. Plus you can add a serial restriction on it (save serial per token). That way the token can't be stolen and used from a different device.

A new version of the CLI has been released! Github webhooks The slipe CLI now has built in support for automatically deploying a Slipe resource using github webhook using the `slipe hook` command. More information on how to set it up can be found on https://mta-slipe.com/docs/webhook.html Updating In order to update your CLI run `slipe update`

A new version of both the CLI and the core have been released! Changes several bugfixes C# reflection is now supported due to metadata being included in compilation Updating In order to update your CLI run `slipe update` In order to update your projects run `slipe update-core` in the project directory Infrastructure From this point on the Slipe website is hosted in a datacenter (instead of a PC at my home) We have also set up a continuous integration / deployment environment so the downloads on the website will always be up to date.

A new version of both the CLI and the core have been released! Events Events have undergone a major refactor, all events now have a `source` and an `eventArgs` parameter. This will allow us to add parameters to events without breaking backwards compatibility. This also aligns more with C# convention. Vehicles The vehicle "lookup" classes have been changed to reflect vehicle types. Exports It is now possible to export static methods from your Slipe resource. For more information on how to do so visit https://mta-slipe.com/docs/exporting.html Updating In order to update the CLI use `slipe update` In order to update an existing project use `slipe update-core` Also we would like to thank those who contribute to Slipe, you guys are awesome! https://github.com/mta-slipe/Slipe-Core/graphs/contributors

We have not yet run benchmarks comparing "regular" Lua and Slipe, but we're planning on doing so in the near future. But by inspecting the generated Lua code and the class library the overhead should not be much more (if any) than a "plain" Lua OO implementation.

It is not, sadly. This is due to the fact that all C# has has to be turned into Lua code in order to be run. With a NuGet package you only get the compiled DLL. If the package is open source however (And if it only uses C# classes / libraries that are implemented in slipe) then you should be able to compile it from the source using Slipe. But keep in mind that only very basic C# libraries are currently implemented in Slipe (and many only partially).

The benefit of doing this isn't necesarily performance, but it's the benefits that a strongly typed language such as C# brings with it. But also the tooling that you're able to use for C#, Visual Studio's intellisense especially is great to speed up your development time. It is, because in the end this project just generates Lua code. And MTA events are implemented in our wrapper as C# events. An example of this can be found in the code snippet on the front page of https://mta-slipe.com

It's basically both. It does allow you to write C# for MTA:SA, and it does this by translating that C# code to Lua.

A new version of both the CLI and the core have been released! Root Events Events which you would want to handle on the rootElement (For example onPlayerJoin) have now been implemented as static events on that class. For example `Player.OnJoin` Defining default classes If you wish to extend a Slipe class and make it the default class for any element of that type you can do so now using the `DefaultElementClass` attribute, you can read more about that on https://mta-slipe.com/docs/inheritance.html New updater The previous updater for the CLI was a bit crap, so the windows installer has been redone as a standalone .exe, you can download this at https://mta-slipe.com/downloads/SlipeInstaller.exe. After that you should be able to use `slipe update` like should have been (but wasn't) possible with the previous updater. Updating an existing project? After updating your CLI you can update your existing Slipe projects using `slipe update-core` in the root directory of the project.

Here's a little teaser of a work in progress first party module for Slipe, called SlipeWPF. For those of you unaware of WPF, it's a GUI framework which allows you to create windows desktop applications. We're also bringing this to MTA. This window, created in Visual studio, will turn into: And all it requires to render it in MTA is this little bit of code: MainWindow window = new MainWindow(); Window guiWindow = CeguiWpfRenderer.Render(window);

The Slipe CLI tool has been updated today. New features include: A `slipe build` command to produce a deployment ready resource, including a `-luac` option to automatically compile the lua files using the MTA compiler. Self updating functionality, no longer will you need to manually update the CLI or core after this update. Exporting and import of modules. Your project can exist of seperate smaller modules, which can be exported and shared with others in the Slipe community. For more information on the CLI visit the documentation on mta-slipe.com

I believe what you're referring to are CLEO mods, whilst CLEO does use the .cs file extension it's not C#, so no that wouldn't work.

We haven't necesarily done benchmark tests, however inspecting the generated Lua code and the OO library used it's not much different than a "regular" Lua OOP library would be. Regarding the data types which do not have an exact conversion, that's exactly why we've created our wrappers around MTA classes. This means that in end user's (or end programmer / scripter) code you will not need to directly use Lua data types returned by MTA functions. But for the purpose of tables these are approached as arrays or dictionaries depending on their usage. EDIT: As a reply to your edit: no, but C# > Typescript IMO Our current MTA project actually consists of several parts of which all but the actual MTA part was written in C#, so this was a perfect way to use the same language on all ends.

Slipe is an open source framework that enables anyone to write scripts for MTA:San Andreas in C# instead of Lua, wrapping all MTA elements and classes and including some .NET Core namespaces. It is based on CSharp.Lua by Yang Huan. Slipe features: Runs on Windows and Linux Built in continuous deployment support with (GitHub) webhooks Object oriented wrappers for all MTA elements Async/await for MTA functions that use callbacks C# style Http requests, sockets and XML methods. Use Visual Studio and its Intellisense Type safety You can find more information about the project on https://prod.mta-slipe.com. Our Discord Our Github The project is still in Alpha, and since it is open source anyone is welcome to contribute

Without code there really isn't much we can do to help.

After a worrying discussion on Discord last night regarding password storage and remember me functionality I've decided to write a tutorial on how it should be done. This guide assumes you are not using MTA's built in account system, but a custom one. Any code shown in this tutorial is purely for illustrative purposes, and is not finished code, you should use it as a guideline, not a solution. The following topics will be discussed in this tutorial: How to hash and salt passwords (register) How to validate a hashed password (login) How to add "remember-me" functionality How to offer password recovery How to migrate from an older hashing algorithm, to a newer one Using a password policy (Extra) How to handle database leaks (Extra) What even is hashing and salting? For the purpose of this tutorial we expect a database structure which is somewhat similar to this: How to hash and salt passwords When you have a user register on your service, that user expects of you to keep their password safe. Whilst it is generally bad practice to use the same password for multiple services there are many users that still do so. Because of this it's crucial that you save the user's passwords in a way that an attacker will be unable to find out the original password the user typed. This includes if they have full access to your database. In order to do this we do what is called "Password hashing" When a user registers, your server receives the user's intended username, (email) and password. Before you save that password to the database you have to hash and salt this, luckily MTA has a function that takes care of this. If you wish to know more about what exactly it does, there's more information at the end of this tutorial. In order to hash this password you use the passwordHash function. This function is relatively slow (by design), so it is highly recommended you pass a callback to this function, so your entire script doesn't wait for it to complete. https://wiki.multitheftauto.com/wiki/PasswordHash local mysqlHandle -- we're assuming this value is set somewhere else in code function register(username, email, password) local player = client passwordHash(password, "bcrypt", {}, function(hashedPassword) -- callback function for hashing the password local handle = dbExec(function(handle) -- callback function for storing the user in the database if (handle) then triggerClientEvent(player, "registrationSuccess") -- inform the user that registration was successful else triggerClientEvent(player, "registrationFailed") end end,mysqlHandle, "INSERT INTO users (email, username, password) VALUES (?, ?, ?)", email, username, hashedPassword) end) end addEvent("passwordTutorial:register", true) addEventHandler("passwordTutorial:register", getRootElement(), register) How to validate a hashed password Once you've saved the hashed pasword to your database you need to do a little bit of additional work when authenticating the user. Luckily MTA offers a passwordVerify() function, which is the counterpart of the previously discussed passwordHash(). What this function does it basically hashes the password in the same way, resulting in the same output hash. https://wiki.multitheftauto.com/wiki/passwordVerify In order to get the account the user is trying to log in to you have to do a query for an account which has the user submitted username, and of which the password matches through passwordVerify. PasswordVerify is also a relatively slow function, thus you should use a callback. function login(username, password) local player = client dbQuery(function (handle) -- callback for the query selecting the user by username local results = dbPoll(handle, -1) if (#results == 0) then triggerClientEvent(player, "loginFailed") return end passwordVerify(password, results[1].password, {}, function(matches) -- callback function for the password verify if (matches) then -- Do anything you wish with the database result to log the player in with the rest of your scripts triggerClientEvent(player, "loginSuccess") else triggerClientEvent(player, "loginFailed") end end) end, mysqlHandle, "SELECT * FROM users WHERE username = ?", username) end addEvent("passwordTutorial:login", true) addEventHandler("passwordTutorial:login", getRootElement(), login) How to add "remember me" functionality When users on your server log in, they often do not want to have to enter their username and password every time they want to log in. In order to satisfy this need you can implement a "remember me" function. What I've seen happen in the past, is people would store the user's password (encrypted) on the client. This is NOT safe, and should never be done! In order to properly use remember me functionality what you would do is upon login in, generate a random string. The longer the better. This random string is what we call an access token. You would then allow the user to log in with such an access token, preferably only once generating a new access token each time one is used. To implement this you would generate that token every time the user logs in, whilst they have "remember me" enabled. You will have to save this token in your database alongside your user. For extra security you could also store the user's serial alongside the access token, you can then validate that the access token is being used from the same device. https://wiki.multitheftauto.com/wiki/Filepath function login(username, password) -- This code should be put in the callback to the dbQuery function, but to keep the example clean that's not shown here if (rememberMe) then local token = generateRandomToken() dbExec(function() triggerClientEvent(player, "loginSuccess", token) end,mysqlHandle, "INSERT INTO access_tokens (user_id, token) VALUES (?, ?)", results[1].id, token) end end function rememberMeLogin(username, accessToken) -- this function handles a user's login attempt dbQuery(function(handle) local result = dbPoll(handle, -1) if (#result == 0) then triggerClientEvent(player, "loginFailed") else -- Do anything you wish with the database result to log the player in with the rest of your scripts triggerClientEvent(player, "loginSuccess") end end,mysqlHandle, "SELECT users.* FROM access_tokens JOIN users ON users.id = access_tokens.user_id WHERE users.username = ?", username) end addEvent("passwordTutorial:loginRememberMe", true) addEventHandler("passwordTutorial:loginRememberMe", getRootElement(), login) How to offer password recovery Offering password recovery requires a little bit more than just your MTA server. Generally password recovery is done with emails. So you would need access to an email server / service which you can use to send an email from an HTTP request. (Like you can do with fetchRemote()). When a user requests a password reset, have them enter the email you registered with. You then fetch a user from the database with this email address. You would then store a password recovery token for this user. This token, just like the remember me token, is a random string. Ideally, you would send the user a link with a password reset form that goes to a webpage where the user can reset their password. You could do this with an external service, like a webserver. Or you could use MTA's Resource web access for it, but if you do make sure you handle permissions properly for anything else that uses this. However another option would be to have the user copy paste the generated token from the email into you server's login window. Which of the two solutions you pick is up to you, my personal preference goes to the one with the link in the email. But in either case the server side logic is the same. When the user attempts to perform password recovery, verify that the token they give you belongs to a user, and then change the password to the newly requested password. Make sure you hash this password the same way you do in your login. function requestPasswordRecovery(email) dbQuery(function (handle)) local result = dbPoll(handle, -1) if (#result == 0) then triggerClientEvent(player, "passwordTutorial:passwordRecoveryRequestFailed") else local token = generateRandomToken() dbExec(mysqlHandle, "UPDATE user_data SET recovery_token = ?", token) -- mail the token to the user, mail implementation depends on the mail server/service you use triggerClientEvent(player, "passwordTutorial:passwordRecoveryRequestSuccess") end end, mysqlHandle, "SELECT * FROM users WHERE email = ?", email) end function recoverPassword(recoveryToken, password) dbQuery(function (handle) local result = dbPoll(handle, -1) if (#result == 0) then -- this is only valid if you have the user request password recovery from ingame triggerClientEvent(player, "passwordTutorial:passwordRecoveryFailed") else passwordHash(password, "bcrypt", {}, function(hashedPassword) -- callback function for hashing the password local handle = dbExec(function(handle) -- callback function for storing the new password in the database if (handle) then -- this is only valid if you have the user request password recovery from ingame triggerClientEvent(player, "passwordTutorial:passwordRecoverySuccess") -- inform the user that registration was successful else -- this is only valid if you have the user request password recovery from ingame triggerClientEvent(player, "passwordTutorial:passwordRecoveryFailed") end end,mysqlHandle, "UPDATE user_data SET password = ? WHERE recovery_token = ?", username, recoveryToken) end) end end, "SELECT * FROM users WHERE recovery_token = ?", recoveryToken) end Besides changing the password, it's important you also delete any access tokens that user might have if you're using remember me functionality. It is also good practice to make recovery tokens expiry after a certain amount of times, and not allow a recovery token to be created whilst one is already in prgoress. This prevents a user from sending a large number of emails from your service. How to migrate from an older hashing algorithm, to a newer one Maybe after reading this topic you realise that your password security is not what it should be. So you want to change your old password hashing / validation logic to the ones explained in this topic. And due to the nature that hashes can not be "unhashed", you can't simply migrate your passwords over. So in order to migrate the passwords what you have to do is when a user logs in, first validate their password with the old hashing algorithm. If this matches, then hash (and salt) it with your new hashing algorithm and save it in your database. Make sure to delete the old password otherwise your password security is not any better than before. Using a password policy Passwords policies are important to prevent your users from picking a password that is too easily cracked / brute forced. Many password policies come in the form of "Must have at least one capital letter, one digit and one number". But that discards that fact that the best way to make your password more difficult to crack, is making your password longer. So in the code snippet below is a function that measures the 'search space' of a password. The search space of a password is the amount of possible passwords there are with a certain combination of characters. In order to use this, you would have to set a minimum password search space when a user registers for an account. This minimum is up for you to set, but be reasonable, you shouldn't expect a user's password to be impossible to remember / create. I recomend playing with the function a bit to see what values you get out of it, and pick something you believe is sensible. function getPasswordSearchSpace(password) local lowerCase = password:find("%l") and 26 or 0 local upperCase = password:find("%u") and 26 or 0 local digits = password:find("%d") and 10 or 0 local symbols = password:find("%W") and 32 or 0 local length = password:len() return (lowerCase + upperCase + digits + symbols) ^ length end -- The below function calls are to indicate the difference in search space for a set of passwords print(getPasswordSearchSpace("a")) print(getPasswordSearchSpace("abc")) print(getPasswordSearchSpace("Abc")) print(getPasswordSearchSpace("Ab!")) print(getPasswordSearchSpace("Ab!0")) print(getPasswordSearchSpace("Mu#9A0h.")) print(getPasswordSearchSpace("This is a demonstration of how easy an incredibly strong password is to remember")) How to handle database leaks If you have reason to believe that your database has been leaked or otherwise compromised, it is important that your first course of action is removing any access tokens stored in your database. Once you have done that you have to inform your users. Whilst when properly hashed and salted it's extremely difficult / time consuming to find out a user's password it is still a possibilty. So you should inform your users of the breach, tell them that their passwords were properly hashed, and they do not need to fear for their passwords immediately. However you should suggest to your users that they change their password either way, just in case. What even is hashing and salting? Hashing has been brought up several times in this tutorial, whilst you do not need to know what it is / does, you might be interested in knowing regardless. I won't be going too far in depth as I simply do not have the knowledge, but the basic idea of hashing is this: When you hash anything, you turn it into a string of characters (or other value) that has no relation to the original input, other than when you hash the original input again, it will always generate the same hash. For example, when you hash the stirng 'banana' using the sha512 hashing algorithm, it will always yield the output: "F8E3183D38E6C51889582CB260AB825252F395B4AC8FB0E6B13E9A71F7C10A80D5301E4A949F2783CB0C20205F1D850F87045F4420AD2271C8FD5F0CD8944BE3" Now hashing can not be reverted, you can not "unhash" a hash, so in order to verify someone's password you hash it again, and see if the two hashes are the exact same. Now this is great, passwords are safely stored. However there is still more to do, salting. Salting is adding some random data to your password prior to hashing it. This prevents when two users (on the same service, or on others) have the same password, that their hashes are also the same. Meaning if one password is compromised, the other password is not. It is important that a salt is random for every user in your application, not one salt for your entire application. Now you might think we didn't do any salting in the code / tutorial above. This is not true, we just didn't do it ourselves. MTA's passwordHash function actually hashes the passwords and salts it, this salt is then stored in the output hash it self, just before the actual password hash. In the case of bcrypt it actually stores a little bit more info in the resulting hash, but you need not worry about that.