Administration / Permission Systems

Safe to say that even if Garry adds official support, people will make their own (Noclip - how it works) but I was curious to see what ideas others would have.

In Garry’s Mod we could easily access the Pkayer meta and change the admin checks, as well as add new checks. In things like SourceMod there’s a set list of permissions that you can build groups off of and assign to clients. What kind of approach is the most sane for something like S&Box?

5 Likes

Some admins will have very different needs, and we can expect a variety of admin solutions regardless of what is done with the default.

Still, being able to have the most basic admin features without any third party addons would be good. Then it could be made extensible to those addons.

A menu for managing usergroups is all we really need by default. Addings/removing groups, setting group inheritance, adding/removing members from those groups, and adding/removing permissions from those groups would be just fine.

A ban database(at least loosely speaking) would be very useful but it should be modular to support more complex solutions with better(heavier) features. It should have a list of everyone who’s been banned, who banned them, why, for how long, and a way to shorten it.

Logs of commands used by admins should be available. What commands are logged should be configurable.

It should be convenient to simply register a permission and either assign that permission’s attribute to a method or check for it within the method itself. The list of permissions networked to clients so they can see it in the admin menu for management.

You could have a set bind by default that opens the admin/command menu, and a hook that third party addons can use to override that and open their own menu and manage all this themselves.

2 Likes

A large number of these are not really applicable to game modes you can make on s&box, it’s not going to be as server-oriented, but more game mode-oriented.

Sure, solutions to these will be made, and better than most gmod methods, but they shouldn’t be there by default.

I don’t see why we can’t just leave this to the community.

4 Likes

I will agree, we’d better to have nice and clean API for everyone, to be able built solutions for personal needs.
For myself I rather use flag-based systems for example, not a groups.

2 Likes

At the most basic level I think we only really need a few things, keeping it simple and making it easy for admin mods to overwrite the default behavior.

  • A way to mark users as admins (think users.txt or something equally basic)
  • Some system that lets addon developers define whether certain permissions should be admin only by default
  • A way for addons to check whether a player has permission to do X
  • Methods for figuring out what permissions are added by the base game/other addons
  • The ability for addons to overwrite the base game’s permission check
  • (Optional) Support for passing custom data/implementing custom checks on a per-permission basis, to facilitate things like whitelisting/blacklisting specific models/entities inside of spawn functions or filtering chat/console commands

This way addons would be able to both have basic permission checks built in and for admin mods to give server owners the ability to reassign permissions based on whatever system they’re using without the base implementation getting in the way much if at all.

EDIT: Of course there should also be a basic yes/no ban system based on SteamID’s, probably shouldn’t forget that one.

2 Likes

I don’t see why we could just get a basic system that’s able to store account-specific data rather than one dedicated to only permissions.

With the account system we can store other stats, such as character data and game data, in addition to a set of permissions (since they’re just data)

All of that is doable with just a simple database (or text file it you want them user-configurable).

Default player permissions don’t make sense in matchmaking games or competitive-oriented games. I feel like this and the system outlined in the topic just don’t make sense sometimes and shouldn’t really be bundled in by default in all games modes.

It’ll be super easy to make an add on that does that stuff for you.

1 Like

I lean strongly towards groups and permissions myself because that’s always worked for me in the past, but you make some pretty good arguments here. I’d like this as well.

Matchmaking/competitive servers could simply have that system disabled by default, so I think it would be fine for a baseline admin system of some form to be there however.

1 Like

Storing account-specific data doesn’t really have anything to do with a permission system, I don’t disagree that having a generic version of one might be nice but it’s a better topic for a different thread.

As for storing permissions on a per-player basis: That sounds like something you’d want to manage through an admin mod, not the base game. The base version should be as simple and as low-impact as possible, having a basic yes/no based around the idea of admins that are defined by their SteamID in a file somewhere really is about as simple as it gets.

2 Likes

I make a gamemode with a custom administration system; a lot of people use that gamemode, hypothetically speaking.

Someone else makes an addon that requires an admin permission, but their addon was not developed to cater to my hypothetical gamemode.

That’s the benefit of a minimal, basic system. The community will make its own improvements to suit different systems, but it’s equally important for even the simplist of addons to function near-universally instead of requiring server owners to write bridges between admin systems. It will quickly become Frankensteins monster.

1 Like

I think it would be nice to have something like CAMI built into s&box.
Means that when everyone rushes to build admin addons, they shouldn’t overlook compatibility.

3 Likes

Just roll a simple role based permission system and have Player.IsAdmin redirect to the permission system. Having admins manually defined in one text file and permissions given out in another area will quckily lead to a mess.

This isn’t something you leave to the community because it is a simple system that should be standardized.

1 Like

This is what SourceMod does and it works fine, honestly. Besides, it’s the offline equivelant for simple servers.

Most advanced plugins and addons will write an automatic system.

1 Like

I don’t understand why they should settle on a subpar and flawed system.

The text file isn’t even simplier: you can grant admin perms by running one command.

grant Jake role admin

1 Like

I really hope that if any of these systems come shipped with the game they will be in form of official addons that you can remove from your gamemode/server and replace if needed. I don’t see a point in hardcoding it on the C++ end or dictating how it should work.

Maybe I’ll want the whole bans and permissions logic running on a separate web server syncing it all across game servers, discord, websites and whatever else.

4 Likes

Do we need a standard? Yes
Do we need a full admin system? No

there should be basic stuff like player:SetUserGroup() and player:GetUserGroup() in gmod (which should be enough for the start) but it would also be very usefull to have something like CAMI (either official or community made) so all addons can use the same interface without having problems

but for the community made one we first need to know how s&box is designed (which only works at the end) to decide which way is the best for everyone

i hope that wont be a mess at start where every addon requires its own permission system :fearful:

2 Likes

From our POV I think we can look at what people did in GMod and work with you to build a framework that works for 80% of people but can be expanded upon for the other 20%. I’d think of this like the tool system in GMod… people can add new tools and remove default tools - but they rarely have to override the entire tool system.

I think you want a couple of things.

Account Data

A system where user data can be retrieved from an external source and set on the player before they join the game. On our end we can default this to a text file with a list of steamids with permission tags, but we should also allow addons to add support to get this information from the web, or from a database.

We should probably split this between global account data that is in every gamemode, and gamemode data which the gamemode saves about a user to restore their character/progress etc on rejoin.

Permission Hooks

A bunch of permission hooks on common things, that the account data system can use by default but can also be overridden and expanded by specialist addon mods.

if ( player.HasGlobalTag( "noclip" ) ) // let noclip
16 Likes

Here is the CAMI spec repository for reference: https://github.com/glua/CAMI

4 Likes

Something I felt GMod was lacking in this regard was a way to express permissions as more than just hooks for specific actions or permissions without context. Especially permissions between an actor and a subject.

A very simple model could be used where addons/gamemodes would register specific “permits”, e.g. “physgun on entity” or “physgun” (in general).

There would effectively be two kinds of API calls:

  1. The thing you mentioned, i.e. player.HasGlobalTag
  2. Something like actor.HasPermitFor(Entity subject, String/Object permit)

A default implementation could delegate a “physgun any entity” permit to a global tag of “superadmin”, and do similarly simple access control for all the other actions, effectively providing a similar system to GMod’s default implementation.

But having this universal way of allowing addons to express the kinds of actions they support, and to allow admin mods to provide implementations for access control, would go a long way to support much more sophisticated use cases without introducing unnecessary complexity.

@stealthpaw here posted the CAMI spec repository which was basically a semi-standardized (many addons used/implemented it) way to manage permissions in GMod, and it was adequate enough for most use cases. Having something like that built-in eventually would be great.

EDIT:

A few examples how this would look in practice:

// in gamemode
if player.HasPermitFor(prop, "physgun") {
   // ...
}

// in some addon
if myPhysEntity.HasPermitFor(traceTarget, "push") {
  // allow this entity to push another entity
  // could delegate to owner of traceTarget
}

if player.HasGlobalTag("superadmin") {
  // allow the player to assfuck someone
}
4 Likes

@garry It would be really great if addons could implement some sort of IAccountStorageProvider and register it. It would allow you to create any provider, and the current provider could be set or forced.

3 Likes