CS2D 
How to write an User-Admin System - AMX2D Tutorial
1 
Offline
help people who've never programmed to create an advanced User-Administration system for the upcoming release of CS2D 0.1.1.5 and its Lua engine.
- An AMX2D Tutorial
PART 1.####################################
How to write a user-admin System - Part 1
Hello, this is part one of the the "How to write a User-Admin System" for the upcoming Lua environment on CS2D 0.1.1.5 on top of the AMX2D System. Today we're going to be covering the initial planning and features of a customized user system with multiple access groups. So let's get started.
1. Prelude - The big problemOne of the biggest disadvantages of only letting server administrators use a RCON-Password based system is that everyone that you give out the password to will have TOTAL control of the server. Now let's picture a situation where the server owner Joe wants to have more people to help check for hackers on his server. Naturally his only option is to give out total control of the server to those he trusts to manage his server. Now let's say that a RCON holder Bob begins to abuse his RCON powers and Joe wants to take back the password or restrict him to only a few commands. What can he do? NOTHING. The only thing that he can really do is to reassign the rcon password and then redistribute out the passwords ALL OVER again. To top that, every time he wants to remove an admin, he has to do the same process over again. Now sooner or later, he will get tired of constantly updating the admins or having to think up of new passwords. There's got to be a better way of doing this.
So what do we do?
Thanks to the ability to write server-side scripts via the Lua runtime tunnel to the CS2D engine, we can now write an authentication system on Lua so we can designate different commands to different people based on their administrative permissions. Now let's say that we need 3 different permission levels, user, admin, and superadmin, and that we have a command that allows you to broadcast some message to everyone, in this case let's call it "/echo", and we only want people with privileges of admin and above to access this command. So what we need to do is to create a function for the player to login, a function to add the user's privilege level to the player list, and a function to check, when a command is called, whether the user has enough privilege to use this command at all.
In order to do this, let's start with the most basic part of the system. The user database. Now we can just use the USGN ids but the problem is, we will need to be able to admin a server whether we're logged into usgn or not, and if we ever need to use the user system for any other mods, well, we'll have to start from scratch again. The ideal solution then would be to create a custom user database, which let's you register, log in, log out, and which records your USGN ID for automatic log in and which also stores your ranking privileges. This not only solves the not logged in users not able to admin the server, but also let's you integrate this system with other mods like a stats mod that can record stats of people without them having to quit the game and go on to usgn to register. Next, we will need a system to parse what the user's privilege actually means. Now for practical purposes, let's assume that the ranks should go in order. An Admin should have all of the privileges of a normal user and a Superadmin should have all of the privileges of a normal user and a regular admin. In this case we have a hierarchy of ranks in which the superadmin has the most permission level and access and a normal user the least (well, besides unregistered users). Here we have a choice to make. If we want a command to be available to regular users, and we have a superadmin, do we write "superadmin admin user" as their permission level in the users database so they can access the normal command? No. The best way to do this is to write their access level as "superadmin" and have the system automatically include him in "admin" and in "user". So here we also would need a function that takes the permission level and go through a permission-rank hierarchy to include him in the other levels as well. Now here you might ask, why not assign each permission level a number and see which level is the higher to determine who can do what. We can, but this also means that if we want a user to be in the permission level "superadmin" and "admin" level only but not in the permission level of "user", then we would be screwed. Finally, we need to actually have a system to determine if a user has enough privilege to access a certain command, meaning that we also need to have a way of assigning a permission level on the command itself. The process is roughly the same as those for the user, the only difference here is that you don't need to create a hierarchy here because you've already created one for the user system. Of course, we could also swap this and create a hierarchy for the commands only which would make more sense (and is indeed what I have done, but in order to introduce the problem in this tutorial, I used it with the user system to get it out quicker) because each user should by reason only belong to one usergroup. Right? Well, it actually does not matter which way you do it, either way is fine.And with that, we have the basic concepts of a flexible user-admin system for CS2D. If you've made it this far, then give yourself a good pat on the back because this will be the most boring and hard part of the process. In the next parts, we will finally begin coding and translating all of the ideas discussed here into a real script.
AMX2D Tutorial - Written by Lee Gao
