All Products
Search
Document Center

DSL syntax for security rules

Last Updated: Jul 29, 2020

DMS Enterprise defines a domain-specific language (DSL) to describe security rules. The DSL is flexible and can describe all security rules theoretically. Enterprises can use the DSL to define their own R&D specifications.

DSL syntax

The DSL syntax of security rules is simple and consists of three parts: if/else, condition, and action. The basic syntax is as follows:

  1. if
  2. Condition 1
  3. then
  4. Action 1
  5. end

The syntax indicates that if condition 1 is met, action 1 is executed.

The syntax can be further extended, that is, the else statement can be followed by an if statement:

  1. if
  2. Condition 1
  3. then
  4. Action 1
  5. elseif
  6. Condition 2
  7. then
  8. Action 2
  9. [else Action 3]
  10. end

The syntax indicates that if condition 1 is met, action 1 is executed. If condition 1 is not met but condition 2 is met, action 2 is executed. If condition 2 is not met, action 3 is executed. There can be no [else Action 3] statement. In this case, no action is executed if condition 2 is not met.

In the preceding syntax, only the if statement is required. There can be zero or multiple elseif statements and zero or one else statement.

  • Conditional statement
    • A conditional statement is a judgment statement used to determine whether a condition is true or false. A conditional statement consists of the following parts: connector AND or OR, operator, and factor (system variable). The following statements are all valid conditional statements:
  1. true // The simplest conditional statement. The return result is true.
  2. 1 > 0
  3. 1 > 0 and 2 > 1
  4. 1 <= 0 or 1 == 1

The return results for the preceding statements are all true.

  • Connectors AND and OR

    • Like in other languages, AND and OR are connectors. The AND connector has a higher priority than the OR connector. However, the priorities of the connectors AND and OR are lower than those of operators. For example, in the 1 <= 0 or 1 == 1 statement, whether 1 is smaller than or equal to 0 is determined first, then whether 1 is equal to 1, and finally whether either of the two conditions is true.
  • Operator

    • Operators connect factors (system variables) and constants to execute related logical operations. The following table lists the operators that are currently supported.
Operator Name Example
== Equal to 1 == 1
! = Not equal to 1 ! = 2
> Greater than 1 > 2
>= Greater than or equal to 1 >= 2
< Less than 1 < 2
<= Less than or equal to 1 <= 2
in Contained in a in [a, b, c]
not in Not contained in a not in [a, b, c]
matchs Regex match idx_aa matchs idx_\\w+
not matchs Not match idx_aa not matchs idx_\\w+
isBlank Is null isBlank
isNotBlank Is not null isNotBlank

Although the preceding operators have priorities, the priorities are hard to remember. Therefore, we recommend that you do not rely on priorities to determine the execution sequence of each operation in a statement. If a conditional statement is complex, enclose the operation that needs to be executed first in parentheses () to change the priority. For example, the execution sequence of each operation in the 1 <= 2 == true statement is unclear. Therefore, you can change the statement to (1 <= 2) == true. In this case, the 1 <= 2 operation is executed first.

  • Factor

    • Factors are variables built in DMS Enterprise and can be used to obtain the context information about the item verified by using security rules. For example, obtain the SQL statement type and the number of affected rows. Different checkpoints of each module provide different factors. For more information, see Security rules.

    • You can directly reference a factor in a conditional statement. For example, you can run the @fac.sql_type == ‘DML’ statement to determine whether the type of an SQL statement is DML.

  • Action statement

    • Actions are performed by the system after the if conditions are met. For example, the system performs actions to allow a ticket to be submitted, select a workflow, allow execution, and reject execution. These actions are the main purposes of security rules. Similar to factors, different checkpoints of each module provide different actions. For more information, see Security rules.
      An action statement is to inform DMS Enterprise of the action to be executed after a condition is met. Therefore, an action statement sometimes contains parameters, such as prompt information and the approval template ID. The following examples show how to use action statements:
  1. @act.allow_execute // This statement informs DMS Enterprise of allowing an action and does not contain a parameter.
  2. @act.reject_execute 'Reason' // This statement informs DMS Enterprise of rejecting an action and returning the corresponding reason. The reason can be customized.
  3. @act.choose_approve_template 3 // This statement informs DMS Enterprise of selecting the workflow whose approval template ID is 3.

Action meanings and parameters for different modules are described later. The most frequently executed action is to select an approval process. For more information, see Approval process.

Cases

Control the number of SQL statements that can be run at a time

  1. if
  2. @fac.sql_count > 1000
  3. then
  4. @act.reject_execute 'The number of SQL statements that can be run at a time cannot exceed 1,000.'
  5. else
  6. @act.allow_execute
  7. end

This action statement informs DMS Enterprise of rejecting the action and returning the corresponding reason if the number of SQL statements is greater than 1,000. The action is allowed if the number is within 1,000.

Allow DML statements to be submitted

  1. if
  2. @fac.sql_type in [ 'UPDATE','DELETE','INSERT','INSERT_SELECT']
  3. then
  4. @act.allow_submit
  5. end

This action statement informs DMS Enterprise of allowing submission if the submitted SQL statement is one of the UPDATE, DELETE, INSERT, and INSERT_SELECT statements.