CuteAuth is an auth provider 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, admin_cuteauth, 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:

• 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

Getting Started
To get started using CuteAuth, download it from the link above. Save the file to your server in location addons/eventscripts/cuteauth/ (you need to create the cuteauth folder).

Next make this your default Auth provider by adding es_load cuteauth to the beginning of your autoexec.cfg file on the server.
Note! Only one auth provider can be in use at a time, make sure there are no other auth provider scripts loaded!

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:
cute adduser "STEAM_0:0:1234567"
(replace the SteamID used there with your ID or IP address)
Note that the SteamID must be enclosed in double quotes!

You can add additional admins using the same method.

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:
cute save

Now the basic configuration is done.

Advanced console commands

If you want more control over the user permissions, you may want to familiarize yourself with the other commands CuteAuth provides. Typing cute 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 cute 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
cute adduserperm "STEAM_0:0:1234567" admin_cuteauth
(again, replace the SteamID with your ID or IP address)

After doing that, you should have the permission required to use cute 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
cute reload

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.

Editing auth file manually

The authentication data is saved to file authdata.txt 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 cute save command.

There are some keywords used in the file, followed by = and then the value. The keywords are:

• ROOT (0) - super admin, has access to any capability unless explicitly denied with DENY keyword.
• ADMIN (1) - admin, has default access to any non-server critical commands unless explicitly denied with DENY.
• POWERUSER (2) - could have some extra capabilities accepted by default than normal users.
• USER (4) - normal user who should not have access to administration functions
• any integer value - 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
• GROUP - define a new group
• INGROUP - assigns the user or group to be member of another group
• DENY - deny the capability explicitly

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:

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

Here is an explanation of the above example file.
The first line tells there is a user with permission level ADMIN with SteamID STEAM_0:0:1012202 who has permission to use admin_cuteauth. He also belongs to two groups, named autoweapon and translocator_admins.

Next up there is a normal user, permission level USER 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, autoweapon, has capability admin_autoweapon. Any user who belongs to this group with the INGROUP keyword has this capability. So the ADMIN at the top of the file has this permission.

The next group is translocator_admins which defines that people belonging to that group have admin_translocator capability as well as all capabilities from group translocator_users.

The group translocator_users tells that everyone belonging to that group has use_translocator 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 cute save command.