Application Level Security |
![]() ![]() ![]() |
A well designed application never allows an end user to reach a command prompt. This leaves restriction of what a user may do within the control of the application itself. Where it is necessary to provide differing levels of access to different users, QM provides several ways to identify attributes of the current user:
A user could potentially escape from the controlled environment provided by the application if the application were to abort. This can be avoided by a combination of the following techniques: Disable the break key. The break key is automatically disabled until completion of the LOGIN paragraph unless it is enabled within that paragraph by use of the BREAK ON command. There should never be a need for use of the break key in a working application. In the unlikely event of needing to re-enable it for a specific user as a result of an application fault, the system administrator can use an extended form of the BREAK command to do this. Use OPTION NO.USER.ABORTS to suppress all options through which a user can cause an abort to occur. This removes the A option from the "Press return to continue" prompt, the query processor pagination prompt and the break key options. Implement the ON.ABORT paragraph. Despite the above techniques, an application may still abort as a result of a run time error or use of the ABORT statement within the application itself. When an abort occurs, QM discards all programs, menus, paragraphs, etc that are running in the process and returns to the lowest level command processor. Before this displays the command prompt, it checks in the VOC file for an executable item named ON.ABORT and, if this is found, executes it. A typical ON.ABORT paragraph terminates the user's session after, perhaps, logging the incident.
Some users such as application developers may need to be able to reach a command prompt. In this case, security subroutines can be attached to R or V-type VOC entries to provide control over what can be done. |