Addon Details

CuteAuth is an [url=http://www.eventscripts.com/pages/Authorization_FAQ]auth provider[/url] to be used as a centralized point to control permissions to functions of other scripts running on the Source server. This script addon registers one capability itself, [b]admin_cuteauth[/b], that controls who are allowed to control the permissions within CuteAuth from client console. This permission defaults to level 0 (ROOT), so no people have remote access to CuteAuth by default. Features: [list] [*]Authentication by SteamID (Internet server) or IP address (LAN server), mode chosen automatically [*]Supports default permission levels (ROOT, ADMIN, POWERUSER, USER) [*]Supports grouping permissions [*]Supports nesting groups [*]Supports explicitly denying permissions [*]Configurable from server and client console as well as using a text editor [/list] [size=18][b]Getting Started[/b][/size] To get started using CuteAuth, download it from the link above. Save the file to your server in location [i]addons/eventscripts/cuteauth/[/i] (you need to create the cuteauth folder). Next make this your default Auth provider by adding [b]es_load cuteauth[/b] to the beginning of your [i]autoexec.cfg[/i] file on the server. [color=red]Note! Only one auth provider can be in use at a time, make sure there are no other auth provider scripts loaded![/color] Next step is adding yourself to admins. If you know your SteamID or IP address (depending on if you are using LAN server or not), you can simply use RCON access to add yourself by using command: [b]cute adduser [i]STEAM_0:0:1234567[/i][/b] (replace the SteamID used there with your ID or IP address) You can add additional admins using the same method. Note that if the user to be added is currently playing on the server, you can also use the userid instead of SteamID or IP address, CuteAuth will automatically convert the userid to the unique identifier. Finally you would like to save the admin information so that it is available the next time you restart the server, to save the info, give this command via RCON: [b]cute save[/b] Now the basic configuration is done. [size=18][b]Advanced console commands[/b][/size] If you want more control over the user permissions, you may want to familiarize yourself with the other commands CuteAuth provides. Typing [b]cute[/b] without other parameters will show all the available subcommands that can be used. Using a subcommand that requires more parameters will show you the description and usage of the command. The console command [b]cute[/b] can be used in client console also. However, to be able to do so, you must have access to admin_cuteauth capability, which is denied from everyone by default to prevent unwanted abuse. To add permission for certain capabilities, such as admin_cuteauth, use the command [b]cute adduserperm [i]STEAM_0:0:1234567[/i] [i]admin_cuteauth[/i][/b] (again, replace the SteamID with your ID or IP address) After doing that, you should have the permission required to use [b]cute[/b] command directly from the client console so you no longer need to use RCON for management. Again, remember to save the changes. For any command that requires you to hand the user identifier, you can also use the userid number if the person is playing on the server. CuteAuth will automatically find out the SteamID or IP address for any valid userid used. If you do a mistake with some of the commands and for example remove some important permissions or groups, there is a rescue available. You can reload the authentication data since the last time you used the save command. To restore back to that time, use [b]cute reload[/b] So, as long as you do not save the changes, you can experiment with the CuteAuth commands as much as you want. If you happen to lose access while doing so, restarting the server will also revert back to the last point you saved the data. [size=18][b]Editing auth file manually[/b][/size] The authentication data is saved to file [b]authdata.txt[/b] in the same folder where cuteauth.py is in. This file is editable with any text editor and is automatically created the first time you use the [b]cute save[/b] command. There are some keywords used in the file, followed by [b]=[/b] and then the value. The keywords are: [list] [*][b]ROOT[/b] (0) - super admin, has access to any capability unless explicitly denied with DENY keyword. [*][b]ADMIN[/b] (1) - admin, has default access to any non-server critical commands unless explicitly denied with DENY. [*][b]POWERUSER[/b] (2) - could have some extra capabilities accepted by default than normal users. [*][b]USER[/b] (4) - normal user who should not have access to administration functions [*][i]any integer value[/i] - permission level, levels 0, 1, 2 and 4 also have special keywords as seen above. Lower number means more power, 0 being the root level [*][b]GROUP[/b] - define a new group [*][b]INGROUP[/b] - assigns the user or group to be member of another group [*][b]DENY[/b] - deny the capability explicitly [/list] Lines that do not begin with any keyword or number are considered to be capability names that the user/group is allowed to use. Here is an example file: [code] ADMIN = STEAM_0:0:1012202 admin_cuteauth INGROUP = autoweapon INGROUP = translocator_admins USER = STEAM_0:1:3025846 INGROUP = translocator_users GROUP = autoweapon admin_autoweapon GROUP = translocator_admins admin_translocator INGROUP = translocator_users GROUP = translocator_users use_translocator DENY = admin_translocator [/code] Here is an explanation of the above example file. The first line tells there is a user with permission level [b]ADMIN[/b] with SteamID STEAM_0:0:1012202 who has permission to use [b]admin_cuteauth[/b]. He also belongs to two groups, named autoweapon and translocator_admins. Next up there is a normal user, permission level [b]USER[/b] with SteamID STEAM_0:1:3025846 who has no special permissions but belongs to group translocator_users. Then there are three groups defined. The first group, [b]autoweapon[/b], has capability [b]admin_autoweapon[/b]. Any user who belongs to this group with the [b]INGROUP[/b] keyword has this capability. So the ADMIN at the top of the file has this permission. The next group is [b]translocator_admins[/b] which defines that people belonging to that group have [b]admin_translocator[/b] capability as well as all capabilities from group translocator_users. The group [b]translocator_users[/b] tells that everyone belonging to that group has [b]use_translocator[/b] ability but can not have admin_translocator capability, even if the user's permission level would normally allow that. Here is a conflict, though. People belonging to translocator_admins belong automatically to translocator_users also. The capability admin_translocator is now both allowed and denied. In these cases it is resolved by checking permission depth. Looking at the Admin's grouping, it goes like: ADMIN -> translocator_admins -> translocator_users. Since the capability is first time introduced in translocator_admins, this will be the effective permission since translocator_admins is higher level group than translocator_users for the ADMIN. The indentation and having spaces around = are not mandatory, but is the form the file is saved into when using [b]cute save[/b] command. [size=18][b]Implicit groups[/b][/size] Starting from version 0.7 every player automatically belongs to one implicit group. The most useful of these groups is _LEVEL4 (underscore, LEVEL4 in capitals) which allows setting for permissions for all players that are of USER level or that have not been explicitly assigned any level even. Basically it works as a fallback group whose rules apply automatically to all new players joining the server unless they are explicitly added to CuteAuth's database.