|
1. Introduction
Security is a very important section of your application. An example implementation will be described in this document.
2. Example
2.1 Simple scenario
For simple maintenance applications often the following security scenario applies: The entity can be maintained by someone with the correct permissions. The permissions are defined in a function role. For all other accessing the entity they can view the information, but not modify or delete the information. In the last situation you often want to hide the action buttons, so it's a true 'read-only' view of the data.
Below you see the implementation of this scenario for the 'Shipping methods'
1. Create a Page_Init event handler, because this is usually the place for you security checks
|
Dim bPermission As Boolean = False
Private Sub Page_Init
bPermission = env.CheckFunction(356)
Me.ReadOnly = Not bPermission
End Sub
|
· Set the 'ReadOnly' property of the Page, in case you don't have permission
· 'Bound' buttons on the page will automatically be hidden.
2. In the Page_Load you have to do 1 final security check, If there are no permissions you have to make sure that never any data can be modified. The user interface will not allow modification, but there is always the possibility that people try to corrupt your data by manually typing URL's in the browser
|
Private Sub Page_Load
If Not bPermission AndAlso bc.Action <> BCDataSourceAction.Edit Then
AccessDenied()
End If
' the rest of the Page_load...
|
This check must be done in the Page_load, because in the Page_Init the DataSource control has NOT been correctly initialized yet. This means the bc.Action does not yet contain the correct value until in the Page_Load event.
2.2 Complex scenarios
In more complex scenarios the security checks often not only depend on a simple function role check, but are a combination of function roles, division and responsibility. The checks can not be done anymore without knowing the information in the database. This means, you first need to retrieve the information from the database before you can perform the security checks. In the traditional ASP application this often required additional queries and/or complex code with 'delayed' updates.
Now the process has been simplified and is much easier to use. It's based on 'server side events' of the data source controls. The events provide a hook for you to create additional security checks based on the information in the business component.
There are usually 3 places where you need to check, 'After Edit', 'Before update' and 'Before Delete'. For each of the 3 actions an event with a corresponding name is called. You can use these events, but there is a simpler way. In many cases the security check is the same for all 3 situations. In this case it's easier to just implement the 'CheckPermission' event.
|
Private Sub bc_CheckPermission(ByVal Sender As Object, ByVal e As EventArgs,
byRef bPermission As Boolean)
‘ Perform additional security checks if necessary
bPermision = checkFunction(123, bc.Prop("CompanyCode"))
End Sub
|
If you set the 'bPermission' boolean variable to 'false', automatically the permissions will be denied. You don't have to do any additional tasks.
Note: Getting the Event to work you need to do:
· Write the event handler as shown above.
· Link the event handler to your data source control. You set the attribute 'onCheckPermission' to the name of the event handler.
You can also use the 3 independent events, but it's not recommended, because you have to implement all situations and you have to call 'AccessDenied()' yourself. For completeness also an example for this situation is given.
Now lets say you can edit an entity if you have function role x or are the manager of the entity. This check requires you to know who the manager is and can only be done after reading the database.
The 'AfterEdit' event handler is the perfect place for this check.
|
Private Sub bc_AfterEdit(ByVal Sender As Object, ByVal e As EventArgs)
' Additional security checks based on the Repository data
If Not env.CheckFunction(12) AndAlso pc.Prop("Manager").Value <> env.HumresID Then AccessDenied()
End Sub
|
The same kind of checks can be done for Updates and Deletes. Say you can create an entity for a group of divisions. The maintenance application allows you to select all divisions, so just before the update is done, you have to resolve the function role using the supplied division.
|
Private Sub bc_BeforeUpdate(ByVal Sender As Object, ByVal e As EventArgs)
' Perform additional security checks if necessary
If Not checkFunction(123, bc.Prop("CompanyCode").Value) Then AccessDenied()
End Sub
|
As you see, also the 'complex' scenarios are now easy to build.
3. Conclusion
Happy Coding =)
Applies to
|