Authorization FAQ

General Questions

What's this AuthorizationService thing I hear about in EventScripts 1.5?

It's a handy little interface for scripts to check whether players are allowed to do things. Advanced scripters can code their own authorization back-end that all scripts on your server use.

What? Are you telling me EventScripts supports "admins" now?

Yep, pretty much. It's extremely customizable.

How can I use it on my server?

To use it on your server:

• Find a script that provides an authorization backend you like. (i.e. find an auth_provider, see below)
• Find cool scripts that support the AuthorizationService interface. (i.e. find fun scripts that say uses_auth, see below)

What is an AuthorizationService provider script?

A provider script just manages your admin list. You can only have one loaded at a time.

How do I find an AuthorizationService provider script?

As of the release of EventScripts 1.5, there are two example AuthorizationService providers that come with EventScripts:

• basic_auth example -- Super-simple. All admins listed in a server variable.
• group_auth example -- More powerful, all admins and groups are stored in a database file. Use the server console to add/delete admins.

Click on either of the above examples to get started storing your admins. Install instructions are provided on the example pages.

Other auth providers can be found on addons.eventscripts.com

How do I set permissions for my players?

There will be detailed instructions with the auth provider you choose for installation and for adding admins. All providers will be a little different (which is the point), but there will be clear instructions provided with the script.

How do I find scripts that use this?

It's highly recommended that scripts make active use of this new feature, so you should see a lot of them coming soon.
For now, there are two examples in EventScripts 1.5 that require 'auth' in order to work:

• adminsay example -- Allows admins to broadcast messages via chat or menus to all players or admins.
• ServerMail example -- Players can send !report messages to the admin. Admins can see a list of all report messages.

EXAMPLES: As they come out, we'll list an example of scripts that support these admin lists here:

• Show Rates Addon by Hunter
• Skin Chooser Addon by Hunter
• WeaponStats by SuperDave
• Skillz Admin by Skillz92
• Fun Effects by SumGuy14
• JetPack by SumGuy14
• AutoWeapon by GODJonez
• (many more examples!)

Why is the AuthorizationService concept so cool?

Well, two major benefits:

• If you use scripts that support auth, you don't need to configure 10 different admin lists for different scripts.
• Admins aren't tied-down to a specific database to define player permissions. If ES had a standard One-And-Only auth provider, then you'd be locked-in to a single method. That's not fun.

Scripter Questions

I'm a scripter-- how do I make say/client commands that use auth?

It's easy. Instead of using es_regsaycmd like this:

es_regsaycmd mega_ban "myscript/myblock" description

you'd use this single line:

clientcmd create say mega_ban "myscript/myblock" "ban_user" #admin

This would create a "mega_ban" say command that called your block. Before doing so it would ensure the user who requested it had access to the "ban_user" permission.

The same things works when you change es_regclientcmd to "clientcmd create console".

So I just replace a single line in my script for my commands, and I support auth?

Yes and yes. Regardless of what backend the server uses, your commands will only run for players who have the permissions you state.

You said "ban_user" above? How did you chose that?

It's just a generic name for the permission that you think sounds right. I typically prefer verb_noun syntax based on what the command actually does. Some other examples might be "view_stats", "reset_stats", "kick_user", "gg_give_level", etc. Admins will sometimes use this permission name so that they can grant/deny access to your commands (assuming their auth provider supports that level of control).

What does #admin mean above? Are there other options?

The #admin part is just the recommended level for the permission you choose. The back-end can completely ignore it, but you can provide it some guidance if it's never heard of your permission name before. In other words, by default, the script recommends that only admins can "mega_ban". If the admin has configured things differently, that will be ignored, but it's a nice hint to the auth-provider.

The following are supported recommendation flags:

• #root - Basically means its recommended to be disabled by default because it's so powerful.
• #admin - You recommends that only admins can use it.
• #poweruser - You recommend that trusted players (and higher) can use it (e.g. clan members)
• #known - You recommend that identifiable players (and higher) can use it (e.g. not STEAM_ID_PENDING).
• #all - You recommend that the command be unrestricted entirely. Anyone can use it.

Do I need to code my own auth provider?

Most scripters won't ever write an auth provider. Their scripts will simply use whatever provider the server has installed. (For example, the admin may load the example group_auth.) Still, if you wanted to code your own auth provider because you have a cool idea for how to store admin lists, see the Advanced Scripter section below.

Advanced Scripter Questions

How do I create an auth provider?

The basic idea is to have something implement the AuthorizationService interface and register it as the auth service. See the no_auth, basic_auth, or group_auth examples provided with EventScripts for details on how to do that. More details soon.