In the existing code it's referred to as an access list.
Basically different resources are registered with the Directory layer. Each resource has an access list which is basically an user id associated with a permission.
Right now the access is an int8_t with the following constants defined for identifying what each value represents:
static const uint8_t READ_ACCESS = 0x01;
static const uint8_t WRITE_ACCESS = 0x10;
static const uint8_t READ_WRITE_ACCESS = 0x11;
static const uint8_t NO_ACCESS = 0x00;
What identifies the resource is a simple std::string object. This makes it flexible enough so that we can provide this functionality to utility developers and new resources can be created at run-time without creating conflicts.
However, because of this we will need to enforce a naming convention for resource names. This will need to be enforced by only allowing utility developers to create resource access lists through our API.
The naming convention should probably be something like this:
- For server resources: "server_resource"
- For workspace resources: "workspace_workspacename_resource"
- For workspace resources created by utilities: "utility_workspace_utilityname_workspacename_resource"
ie: In the Directory database in trunk there is an existing resource called "server_add_new_user". This is a resource that is used to determine who can add new users to the server.
In this case, a read access would only allow to see who has access to the resource, and a write access would allow to actually use the resource (Add new users to the server).
There is one more thing that we've talked about which is Server and WorkPlace roles. I haven't implemented this yet, but I have a good idea of how to do so (probably sometime next week).
I think the Role code should be more like a script (not literally of course). All it will do is know how to give the person the role is given to, the right access, to the right resources. So if a role of Server Administrator is applied to a user, then the Role code will give the user read/write access to most server functionalities, such as stopping the server (server_stop), restarting the server (server_restart), adding new users (server_add_new_user), etc... This should be easy to implement. We just need to find out what resources to give access to for each Role.
