22.07.2011, 00:54
Has anyone ever thought of a global permissions system where any coder could just add one small little hook into each command they have it would be based on a plugin? I was browsing through the Bukkit forums for Minecraft, and I use the Permissions Plugin for everything I have on Minecraft. Well the way it's designed, and how it's used really interests me, and I thought it would be pretty cool if someone attempted to port it to SA:MP. What I thought was kinda based off of what the original Permissions plugin had.
> A folder containing all data relating to the permissions
scriptfiles/Permissions/
In that directory will contain the necessary contents of the needed permission nodes and desired groups. Say the plugin is designed to read off of one file formatted in some similar way to the original Permissions file. Of course, they use YAML or .yml files, which can organize stuff quite a bit. YAML supports most languages, and hopefully it can be brought into SA:MP! On their main website, they have C/C++ libraries ready to use. But onward with the topic.
Where the groups would be located would say be scriptfiles/Permissions/Groups/groups.yml - inside it would look something like this:
And so on. With the ranks node for User>Info>Rank - you could set maybe the level, or ID of the certain group. Could be used for later things such as /permissions promote <user> - which would get the current user's group ID, and set it to a value 1 higher. Or add a command and skip that all, /permissions group set <user> <group-to-set-to>.
As for user setting, you would navigate to a directory such as: /scriptfiles/Permissions/Users/users.yml. Inside the users.yml, you would find something similar to the groups.yml file, with indentations (NOTE: YAML uses 4 spaces as an indentation, not tabs) and it could look something like this:
For coders, I'm not quite certain what the hooking code would actually look like, but I'm guessing it could be done with maybe something like:
Obviously it would require some help here from the plugin developer to create those functions.
The Functions List:
I find that these could be some maybe functions created for coders, to help them out more!
Reason I put name[] instead of a playerid paramter, is because SA:MP's player IDs are only temporary, and stay as long as you stay on the server. In the users.yml, it would be written into the file as your name, not your playerid.
This is what I have so far to write. Yes, it's almost exactly like the Permissions plugin from Bukkit, as I said it's like someone would port it. I'll change updates if I ever come up with more stuff, but I'd like to see what you guys think.
> A folder containing all data relating to the permissions
scriptfiles/Permissions/
In that directory will contain the necessary contents of the needed permission nodes and desired groups. Say the plugin is designed to read off of one file formatted in some similar way to the original Permissions file. Of course, they use YAML or .yml files, which can organize stuff quite a bit. YAML supports most languages, and hopefully it can be brought into SA:MP! On their main website, they have C/C++ libraries ready to use. But onward with the topic.
Where the groups would be located would say be scriptfiles/Permissions/Groups/groups.yml - inside it would look something like this:
Code:
groups:
Admin:
info:
rank: 3
permissions:
- 'permissions.node'
- 'permissions.node'
Moderator:
info:
rank: 2
permissions:
- 'permissions.kick'
- 'permissions.modchat'
- 'permissions.modchat.disable'
User:
info:
rank: 1
permissions:
- 'permissions.help'
As for user setting, you would navigate to a directory such as: /scriptfiles/Permissions/Users/users.yml. Inside the users.yml, you would find something similar to the groups.yml file, with indentations (NOTE: YAML uses 4 spaces as an indentation, not tabs) and it could look something like this:
Code:
users:
Toni:
group(s): <-- Maybe a multi-group feature?
- 'Admin'
permissions: <-- You could use this to exempt players from certain permission nodes, so if you don't trust a certain co-owner or admin, you could just certainly deny the permission node there.
- 'froob.denied.from.using.abuse'
Hiddos:
group(s):
- 'Moderator'
- 'User'
permissions:
- 'deny.*' - certainly you wouldn't trust Hiddos with admin. he could be a silly abuser! joking :D
^ - This is where coders / users could use a asterisk to define ALL permissions node under that parameter, example: permissions.vehicles.* would allow players to do anything relating to permissions.vehicles.
pawn Code:
CMD:ban(playerid, params[])
{
PermissionsCreate("admin.ban");
//Ban Code
}
The Functions List:
I find that these could be some maybe functions created for coders, to help them out more!
pawn Code:
native PermissionsCreate(permission-name[]) - Example: PermissionsCreate("admin.ban.ip");
native PermissionsCreateAsterisk(permission-node[]) - Example: PermissionsCreateAsterisk("admin.ban.*");
native PermissionsReload(); - Could be called under any callback to reload any changes to the configuration, or permissions files.
native PermissionsShowGroups(bool:order-by-name, (optional: with / without rank)); - Called under any command to list all of the groups. True or false, list the group names alphabetically. See below @ PermissionsCreateGroup for information on rank.
native PermissionsShowUsers(bool:order-by-name); - Called under any command to list all of the users inside the users.yml file, this list will probably your VIP groups, extra groups, or Staff.
native PermissionsCreateUser(name[], group id); - Example: A command with /permissions add <user/id> <group id> You could then retrieve a name with GetPlayerName, and get the group id manually.
native PermissionsCreateGroup(group name[], (optional: rank id)); - Example: A command with /permissions add group <user/id> - PermissionsCreateGroup("Admin", 3);
native PermissionsRemoveUser(name[]); - Example: /permissions remove <user/id> PermissionsRemoveUser("Toni"); would remove me from the users.yml.
native PermissionsRemoveGroup(group name[]); - Example: /permissions remove group <group id> PermissionsRemoveGroup("Admin"); would remove the admin group.
native PermissionsSetUserGroup(name[], group name[]) - Example: /permissions set <user/id> group <group id>
This is what I have so far to write. Yes, it's almost exactly like the Permissions plugin from Bukkit, as I said it's like someone would port it. I'll change updates if I ever come up with more stuff, but I'd like to see what you guys think.
