[Tracking issue] Rights rework | Rights via api/webinterface

[Splamy]

Tracking issue for everything related to rights.

• [ ] Rights file per bot
• [ ] Rework processing order
• [ ] Simplify matching / nesting
• [ ] Rename to 'permission' (Note: 'rights' was originally chosen to differentiate from the ts3 'permission' system; however the term is not quite correct here.)
• [ ] Default permission groups
• [ ] Rights via cmd/api
• [ ] Rights via webinterface

[Mezir]

@Splamy when do you plan to add this feature so that each bot has a separate permission file?

[zumoshi]

As per your request on #861, this is a copy of my messages there so that issue could be closed/merged.

---

Is your feature request related to a problem? Please describe. While the API is perfectly capable of creating new bots, currently the first bot has to be created manually (either through commands from stdin or modifying config files followed by restarting the server). And the API key can only be created by manually joining the TS server and sending a pm.

Describe the solution you'd like The ability for an initial API token to be set before creating the first bot. This could either be from an environment variable (for a superuser) or a config file entry (ability to set permissions similar to the IP filter, but with a token followed by permissions it should have).

Describe alternatives you've considered As stated in #818, If the admin connections were coming from a single IP, one could ignore the token altogether. but that is not always the case. (or in case of shared hosting, the admin may not be the only person able to use that IP) Another alternative is to create an API token manually once with a dummy identity, then copy the database from that instance to any new instances created so they would come with a token. But this approach prevents the generation of a new random token for each instance reducing security.

The main use case is automated creation of new instances using an API, which would use the webapi to create new bots as soon as the instance is up. For example from a whmcs provisioning module.

---

A followup of this issue (feel free to ask me to create a separate issue for it if you want), is modifying rights through the API. Assuming the server was created in unattended mode, There would be no UID in the roles file for the admin.

Ideally we wouldn't need to have a second web agent in the same server providing an API just for the purpose of modifying TS3AudioBot's config files from the provisioning module which may be on shared hosting and not have direct access to the files.

How to implement this is up to you, but these are some ideas:

• A method to read the rights.toml file. And a method to upload it, which would check the syntax, and if no errors replace the file and run !rights reload

• Specific methods to set each value, similar to the settings api. Something like:

  • /rights/list (list of rules)
  • /rights/add (creates new empty rule)
  • /rights/del/{rule} (deletes rule by id)
  • /rights/get/{rule}/{path} (e.g. /rights/get/0/groupid -> [2])
  • /rights/set/{rule}/{path}/{value} (e.g. /rights/set/0/useuid/%5B%22M8QUkY1Fx43ItB66HFFr0CimBDo%3D%22%5D)

• Alternatively if you have more time the api can be more sophisticated, with methods to list all available permissions, or specific methods for adding a userid or group to a rule. rather than just replacing a json value in the toml file.

Edit: I see now that this was already mentioned in issue #651. Can I help get this feature faster? I can make a pull request if you help me with choosing the approach and pointing me to the sections needing modification.

[pmm26]

This would help a lot