Common Approaches to Locking Down UI
Software developers often use message dialog boxes to inform users that they do not have access to certain features. While it's a prevalent practice, it creates a number of difficulties. The primary problem is that dialog boxes interrupt the flow of a skillful user, thus hampering productivity, and may even be an unfavorable annoyance. Moreover, the reactive nature of dialog boxes does little after the user has dismissed the dialog and forgotten the box's message. Lastly, a dialog box does not provision for the restriction of privileged information (e.g. if a field is present on a screen, even a well placed dialog box will not prevent sensitive information, such as salary, from being shown by a data bound text box).
Hence, we must now ask how to architect a generic solution that will allow developers to specify which user interface elements should be enabled or visible and which should be disabled or invisible based upon the user's role. Ideally the solution should be easy to implement (i.e. the less code the better). The most common technique would have the developer code a method to secure individual controls; called from the form load. While effective, this method is tedious since it requires manual coding. Each form would require another method to be coded.
Another approach is to subclass each control and create custom properties that can be used to specify for which roles the widget is enabled/visible. Like the last solution, this is effective but tedious. Do you really want two types of buttons on the form: a "SecuredButton" and "normal button"? And, more to the point, do you want to subclass every .NET control? Do you really want to subclass a frame? The answer, obviously, is no.
UI Lockdown Code Conference Style
There's a better way to handle user permissions on forms: Microsoft Windows Forms Extender Provider Controls. What is an Extender Provider? Microsoft's .NET documentation says "An extender provider is a component that provides properties to other components. For example, when a ToolTip Component (Windows Forms) is added to a form, it provides a property called ToolTip to each control on that form. The ToolTip property then appears in the Properties window for each control and allows the developer to set a value for this property at design time."
The property provided by the extender provider actually resides in the extender provider object itself and therefore is not a true property of the component it modifies. At design time, the property will appear in the Properties window for the component that is being modified. At runtime, however, the property value is referenced (first located then referenced) by iterating through the extender control rather than through the component itself.
|Figure 1. In this figure, an instance of an extender control (SecurityEnableComponent1) appears in the tray area of the form.|
OK, here comes the complicated part. What this means is that we can create a suite of extender provider controls such as DisableControl, HideControl, etc. When we drop one of these extender controls onto a form, the control appears to "add properties" to other controls on the form. We can put values into these "extended properties" that identify the specific roles that have permission to access the widgets.
Figure 1 shows an instance of an extender control that has been placed onto the form (circled blue). The control appears in the tray area of the form because it is a non-visual control (i.e. a component class). The extender control is named SecurityEnableComponent1. Notice how the properties window now has the property SecurityEnableComponent on SecurityEnableComponent1 (in red). This is the property that has been added as a result of the extender control. We set the value of this property to "Manager."