If protected operations (operations) exist in an object that can be done only by authorized user, then the object contains also the Permissions
page. The page contains a list of all permissions for the object that cannot be changed by a user and it depends on the object type (e.g. the permission list of the PmRoot
object on the Permissions
page is different than the permission list of the PmPanel
object on the Permissions
By the Edit permissions button it is possible for each permission to edit a list of the authorized user groups for which the protected operation is allowed.
Thanks to the definition of the permissions in objects by a list of authorized user groups (and not by the local or network users), it is possible to easily add or remove the local and network users. Those are put into proper user groups and no changes in the configuration of individual objects are needed. The change is done only centrally in the Users configurator. Then the groups have the logical sense and they are used only for the definition of permissions (e.g. $ADMIN, $OPER, GUESTS, etc.).
System users and user groups overview:
: system group of users, represents any local or networkuser (logged in, non-logged).
: system group of users, represents any local user (logged in, non-logged).
: system group of users, represents any network user (logged in, non-logged).
: system group of users, represents group of users with administrator permissions.
: system group of users, represents group of users with permissions of normal user.
: system user, represents a net non-logged user.
Basically there are two possibilities how to create the request for performing protected operation on the running application:
- request arose locally: the list of user groups according to permissions is went through and compared with the local user that just logged in
- request arose in the network: the list of user groups according to permissions is went through and compared with the network user mentioned in the network request to the operation
Validating the permissions of the logged user in order to execute the protected operation. The evaluation itself (over the User
object)follows these steps:
1) Determine if the request for an operation was created locally or in the network.
2) Determine the identifier of the local or network user that evoked the request. In case of combination of the network users defined by name/password and IP address there may be two identifiers.
3) Comparing the user identifier with the user groups according to permissions. The operation is allowed if the user is a member of one of the mentioned user groups. If there are two identifiers present, the comparison is executed for each one and one successful result is sufficient for operation execution.
All comparations when finding an occurance of the user identifier in the list of authorized groups, ends with the success immediately after finding the group where the user is a member. If the whole list is passed and the user is not found in it, the search ends with the failure and the operation is not allowed.