Access Control List: Difference between revisions
No edit summary |
mNo edit summary |
||
Line 1: | Line 1: | ||
MTA includes a complete Access Control List (ACL) that allows you to secure and limit access to the server, | MTA includes a complete Access Control List (ACL) that allows you to secure and limit access to the server, its functions and resources in any number of ways. | ||
The key concept of MTA's ACL (and ACLs in general) is that you're giving a specific object a set of rights. In MTA's case objects are one of two things - resources or users. There are numerous ''rights'' available in MTA - these mainly focus on server-side scripting functions. | The key concept of MTA's ACL (and ACLs in general) is that you're giving a specific object a set of rights. In MTA's case objects are one of two things - resources or users. There are numerous ''rights'' available in MTA - these mainly focus on server-side scripting functions. |
Revision as of 19:47, 2 October 2009
MTA includes a complete Access Control List (ACL) that allows you to secure and limit access to the server, its functions and resources in any number of ways.
The key concept of MTA's ACL (and ACLs in general) is that you're giving a specific object a set of rights. In MTA's case objects are one of two things - resources or users. There are numerous rights available in MTA - these mainly focus on server-side scripting functions.
What this essentially means is that the ACL allows you to choose exactly what functions a resource or user can perform. This can obviously be invaluable - for example preventing all your server's players from being able to ban each other, or preventing your new untested resources from doing the same.
Of course, with great power comes great responsibility and it is very easily possible to completely break resources - for example, disabling spawnPlayer for all resources would be a Bad Thing. Of course, there are situations when you might want to do this - if you want to force all your resources to use a spawn manager resource for example, but even this is somewhat draconian.
How it works
There are three ways you can modify the ACL - how you do it depends who you are.
HTTP Interface
You can use the webadmin http interface to modify the ACL in your web browser. This is by far the easiest way to do so. Just make sure the webadmin resource is started on your server and visit http://ServerIP:HttpPort/. You can then use the two sections - ACLs and Groups. ACLs allows you to create your Access Control Lists - lists of rights. Groups allow you to group together collections of users and assign ACLs to them. For example, the ACLs section allows you to specify that the Admin ACL has access to the start console command. You can the go to the Groups section and create an Admin group that has access to your Admin acl. You can then add users to your Admin group.
XML file
You can modify the ACL.xml file manually. This has a fairly straightforward syntax, but it can get a bit confusing at times. If you do it while the server is running, don't forget to call the scripting function aclReload ("start runcode", "run aclReload()") so the new ACL is loaded, or otherwise stop your server before modifying. This also prevents your changes from being accidentally overwritten by the server.
Scripting functions
You can use a large number of ACL scripting functions to modify the ACL on the fly. Of course, you can (and really should!) limit access to the ACL functions with the ACL.
- aclCreate
- aclCreateGroup
- aclDestroy
- aclDestroyGroup
- aclGet
- aclGetGroup
- aclGetName
- aclGetRight
- aclGroupAddACL
- aclGroupAddObject
- aclGroupGetName
- aclGroupList
- aclGroupListACL
- aclGroupListObjects
- aclGroupRemoveACL
- aclGroupRemoveObject
- aclList
- aclListRights
- aclReload
- aclRemoveRight
- aclSave
- aclSetRight
- hasObjectPermissionTo
- isObjectInACLGroup