0726-0729
Page 726
Figure 29.2.
This main window has
all top-level menus
visible and enabled.
Figure 29.3.
In this main window,
the top-level menu item
Admin is completely
hidden from a user who
does not have the
oe_admin role.
You can apply similar methods and principles to enforce application security for windows and specific controls. In some cases, disabling or hiding a menu option prevents access to a particular form. Under these circumstances, no additional security should be required to prevent a user from accessing the form. However, it is more common for a particular form to be read-only for a specific application role or group of roles. In some cases, specific controls must be made read-only or disabled based on the role of the user.
Page 727
Figure 29.4.
In this main window,
the menu option Look-
Ups is disabled for a
user who has the
oe_manager role.
As with menu options, you can design tables to drive application security for access to forms and specific controls. Listing 29.4 demonstrates one possible implementation of data-driven window- and control-based application security.
Listing 29.4. This DDL script creates tables that can be used to dynamically alter the states of windows and controls at runtime.
CREATE TABLE oe_window_privileges ( app_role VARCHAR2(20) ,window_id VARCHAR2(10) ,read_only NUMBER(1) NOT NULL ,CONSTRAINT window_priv_pk PRIMARY KEY (app_role, window_id) ); CREATE TABLE oe_control_privileges ( app_role VARCHAR2(20) ,window_id VARCHAR2(10) ,control_id VARCHAR2(10) ,visible NUMBER(1) NOT NULL ,read_only NUMBER(1) NOT NULL ,CONSTRAINT cntrl_priv_pk PRIMARY KEY (app_role, window_id, control_id) );
The same potential problems that apply to data-driven menu security apply to data-driven window and control security. First, there must be a method of determining the APPLICATION role for a specific user. If application security is being applied to menu options, the same APPLICATION role should apply to window and control-based security for a specific user. The
Page 728
user's role would then need to be read only once and stored in a global variable to be used whenever security restrictions must be checked. Within the table being used to determine which windows and controls can be accessed for a particular role, there must be a way to uniquely identify a window as well as the individual controls within a window. Again, the problem with this approach is that the identifiers must exactly match those being used by the client application. As is the case with menu options, many development tools have only a Tag property available to use as this identifier. Any mismatch between identifiers in the application and the identifiers being stored in the table will result in a breakdown of application security.
Code used to retrieve security information from the database and alter the states for windows and controls should be placed in the appropriate constructors. Depending on the development tool, this can be a problem because objects that need to be referenced might not be instantiated at the time the window is constructed . For example, in C or C++, the constructors for a window's controls are typically called from within the constructor of the window itself. The application should retrieve values from the database before calling the constructors for any controls that might be affected by application security. The controls themselves can then be disabled or hidden as needed.
In MFC applications, for example, the Create member function is used to position and set the style for most interface objects. An application can set the style constants dynamically at runtime by calling Create with style constants read from the database. For example, in Windows 3.1, the ES_READONLY style constant can be passed to the Create member function of an edit control to make it read-only, and any control object that inherits from CWnd can use the WS_DISABLED style constant to disable a control. If the objects are constructed as part of a dialog resource, messages can be sent that will have the same effect. For example, EM_SETREADONLY can be sent to an edit box to make it read-only at any time after it is constructed.
In some cases, an application will need to hide controls based on the current user. In this case, the objects themselves should simply not be constructed, if possible. Note that the oe_control_privileges table in Listing 29.4 contains the columns visible and read_only. The read_only column should be redefined for C and C++ applications to accept style constants instead of the numeric representations of the Boolean values TRUE and FALSE. If a control will not be visible, no values need be supplied for the style constant.
The order in which objects are constructed is not as much of a concern with most Windows GUI design tools, such as PowerBuilder and Visual Basic, unless controls are being placed dynamically at runtime. In Visual Basic, for example, all controls that were placed on a form at design time can be referenced in the load event (constructor) of a form. Unfortunately, Visual Basic controls do not provide all the flexibility of the analogous MFC objects. The Visual Basic text box, which is roughly equivalent to the MFC CEdit class, does not provide a read-only property. However, the Windows API can be used to set a Visual Basic text box read-only at runtime, using the SendMessage function and the hWnd property of the text box.
Page 729
The development tool being used will have an impact on the structure of the tables being used to drive application security. Tables such as those in Listing 29.4 will fit most situations, with minor modifications. Because the application must interpret the values in the tables based on the columns in which the values appear, the actual implementation is not important as long as it is applied consistently. For example, the oe_control_privileges table does not have an enabled column. However, the application will set the control as enabled rather than read-only based on the data in the control. As mentioned previously, if the application is being developed using C or C++, it might be preferable to replace the read_only column with a style column used to store a style constant or a combination of style constants to be applied to the control.
Regardless of the development tool or data structures you use to drive the interface, follow the same basic steps to enforce application security for windows and controls. First, in the constructor of a window, security information pertaining to the window is read from the database. This information must then be interpreted by the application through a process that maps values from the database to controls and properties. Finally, the properties of controls must be set based on this information. The entire process can become more complicated when a particular window serves more than one purpose. For example, in many cases the same form that is used to add a record is used to edit a record.
Typically, different rules or security restrictions will apply to adding a record versus editing an existing record. In these cases, the tables provided as an example in Listing 29.4 will not suffice. One possible solution is to define a constant to be used by the application to determine whether the window is being used to add a record or to edit one. You could add another column to the tables in Listing 29.4 to differentiate these modes. This column would also have to be part of the primary key. The application will now be required to prepare a different SELECT statement, based on whether the window is in add mode or edit mode.
Listing 29.5 provides a simple example of how these concepts can be applied to application security using Visual Basic. The example is based on an order detail entry form that is used to add records by all salespeople. The example assumes that the Date Shipped field is updated by another process (such as the shipping department filling the order and creating a packing slip). It also assumes that only a manager can override the default price read from the database, and can do so only after the item has been added to the order. Although this simple example might seem a bit contrived, these types of rules are sometimes enforced to provide an additional audit trail for unusual transactions.
Listing 29.5. An example of enforcing application security for windows and controls in Visual Basic.
Sub SetSecurityStates(dsControlSecurity() As Dynaset) Dim iControlID As Integer Dim bVal As Integer Dim iRet As Integer
continues
