Dealing with Access Permissions

This section covers programming handling of Iotellect Server security and permissions issues.

Accessing Context Data

Many methods of the Context and ContextManager interfaces accept a parameter of type CallerController. Caller controller is an object that incorporates effective permissions of the calling side. There are two generic rules for using caller controllers:

  • Any server-side code (device drivers and plugins) must pass an instance of CallerController to every method that accepts it. Failure to do so will result to the None effective permission level of the calling side, thus making most calls fail with an error or return null values.
  • Any remote code (applications using Iotellect Server API or Java-based Agents) should use methods that do not accept caller controller or pass null as its value. This will perfectly work since client-side code does not perform permission checking, while the requested remote server-side operation will anyway incorporate permission level obtained during authorization (call to login() function of the root context).

Obtaining Caller Controller

Server-side code may obtain caller controllers in several ways:

  • Create an instance of UncheckedCallerController to suppress any permission checking and get full access. This should be done only by some system code that is not assumed to execute operations with permissions of a certain system user.
  • Get a caller controller by calling getCallerController() method of ServerContext (or getCallerController() method of DeviceContext). This controller will incorporate permission of system user owning the device account. This way of getting caller controllers mostly applies to Device Driver code.

Extending Contexts

When device driver of server plugin adds definitions of variables, functions or events to a server context, it may assign custom permission levels to them using VariableDefinition.setReadPermissions(), VariableDefinition.setWritePermissions(), FunctionDefinition.setPermissions(), and EventDefinition.setPermissions() methods. If permission level of the definition is null, it will match permission level of the parent context. Note, setting definition's permission levels lower or equal to context's permission level is meaningless.

To get predefined values of different permission levels, use the following code:

Permission Level

Code

None

ServerPermissionChecker.getNullPermissions()

Observer

ServerPermissionChecker.getObserverPermissions()

Operator

ServerPermissionChecker.getOperatorPermissions()

Manager

ServerPermissionChecker.getManagerPermissions()

Engineer

ServerPermissionChecker.getEngineerPermissions()

Administrator

ServerPermissionChecker.getAdminPermissions()

Manual Permission Checking

Sometimes it might be necessary to check permissions of a specific authorized entity (represented by a CallerController). This can be done via server's permission checker represented by PermissionChecker interface.

An instance of permission checker can be obtained via getPermissionChecker() method of a ServerContextManager that, in its turn, is returned from getContextManager() method of a properly parameterized server contexts (e.g. contexts inherited from BaseServerContext, EditableChildrenContext or EditableChildContext).

Effective permission level of a CallerController in a specific context can be checked via(CallerController caller, Permissions requiredPermissions, Context accessedContext) method of a PermissionChecker.

Here's an example:

boolean checking = caller.isPermissionCheckingEnabled();

boolean admin = getContextManager().getPermissionChecker().has(caller, ServerPermissionChecker.getEngineerPermissions(), this);

if (!admin && checking)
{
throw new ContextException("Not an administrator");
}

Was this page helpful?