Welcome!

SAP Authors: Greg Schulz, Gilad Parann-Nissany, Noel Wurst, Kevin Benedict, RealWire News Distribution

Related Topics: PowerBuilder, .NET, SAP

PowerBuilder: Article

DataWindow Magic: Menu Security

Designing and implementing your own

Security is a must for most corporate applications. This article will give you a starting point to designing and implementing your own. We will do it with a table that is added to the example database and implement it in ancestor code. The idea is that you should only have to add rows to a table to implement your security.

The Table
The security table will provide a means to turn on and off controls and menu items as our inherited objects are constructed.

Security

Login_name varchar(20) PK

Application varchar(20) PK

Item_type varchar(10) PK

Item_name varchar(20) PK

Priviledge varchar(2)

 

Security

Column Name

Data Type

Description

Login_name

Varchar(20) PK

The login name of the user

Application

Varchar(20) PK

The name of the application

Item_type

Varchar(10) PK

Might be window or menu or a type of control in a window like a command button. We will only cover menu types in this article.

Item_name

Varchar(60) PK

Menu item name like "File" or "New"

Priviledge

Char(2)

NULL = no priviledges

R = read only

I = Invisible

W = read/write

The Item Datastore
Although I had several choices I decided to create a datastore that would return all of the specified item types for an application. If I was in a menu I could look for menus. If I was in a window I could look for windows.

Ds_security_list data source

SELECT "security"."application",  
"security"."item_name",  
"security"."priviledge",  
"security"."login_name" 
FROM "security" 
WHERE ( "security"."item_type" = :as_itemType ) AND 
( "security"."application" = :as_appName ) AND 
"security"."login_name" = :as_loginName

This will give you all the items and privileges for the supplied application name and itemtype.

Now that we have this we can start our menu.

The Root Menu
Menus don't have constructors. We are going to implement our security with a function. I created a new menu and added a function called mf_loadSecurity.

Here is the code for mf_loadSecurity

M_root.mf_loadSecurity(as_loginName, as_appName)

// First get a list of all menu security items
datastore lds
lds = create datastore
lds.dataobject = "ds_security_list"
lds.settransobject( sqlca)

// Now retrieve
long ll_row, ll_max
ll_max = lds.retrieve(as_loginName, as_appName, "menu")

Let's discuss this code a little before we continue. As you'll see, handling a menu programmatically, for any reason, is necessarily complex.

The menu object has an array of items in it. Each of those items is another menu item that also has its array of items.

If the array of items in any particular menu item has no elements, then that is a bottom level menu item. If there are elements in the array then those elements compose the sub-menu for that menu item.

You might want to read the last couple of paragraphs a few times. Here, let me give you an example.

For my article I created a menu object inherited from m_root and named m_main that looks something like the following:

I didn't want to confuse the issue too much so I put in only the File menu option along the top. Under File I put New and Exit. Under New I put Test 1, Test 2, and Test 3.

Here is how the menu looks in the menu painter.

Note that I have an item called Invisible in the menu. This comes from m_root. I put it there to implement system-wide shortcuts. The visible property for this is FALSE.

For our test we are only concerned with the Test 1, Test 2, and Test 3 menu items. I am going to make Test 1 read-only and Test 2 invisible.

Since we have this metaphor of arrays of menu items within menu items we are forced to use recursion. Don't worry, though, we'll walk through it.

Recursion
Recursion has been known to throw even the bravest programmer into fits of apprehension. Essentially we need two functions. One just fires off the recursive function for every element in its item array. The recursive function will check to see if the arguments to itself are a match. If so, it returns itself. If they are not then it loops through its own item array, calling itself for each element.

The function mf_loadSecurity calls the recursive function. The first part loads the datastore that holds the security list. We have already defined that. The mf_loadSecurity takes two arguments. Those are the arguments that are used to retrieve that array.

Once we retrieve that datastore we have a row for every row in the security table that matches the login name of the user and the application name has an item_type of ‘menu'. At this point we are not worried about the window security. The mf_loadSecurity will loop through all of those to work its magic.

Note that I could have gone the opposite route and looped through each and every menu item recursively then done a singleton select in each one. I chose the former because I think it will be rare that we will have a row for all of the menu items and thus this will be a faster response time. Here we do one call to the server for the result set rather than one call for every menu item.

I loop through every row. I extract the privilege and the item name for each row. I call the recursive function for each row, looking for the item. I pass myself and the item name.

The recursive function mf_findMenuItem will return the found menu item or a null. If it is a null then the menu item was not found.

If the item was indeed found then I set the appropriate property for that menu item (depending on the privilege that I just read).

If you look closely at the code for mf_loadSecurity while reading the explanation you should be able to understand rather easily.

mf_findMenuItem
mf_findMenuItem is the recursive function. It calls itself from within itself. Recursion is not terribly complicatee but you have to remember to give yourself some way to unwind from the function otherwise you waste a lot of processing.

M_root.mf_findMenuItem(menu amenu, string as_name)

//Are we there yet?
if amenu.text = as_name then
return amenu // Yes, we are... let's go home
end if
// This wasn't a match, we have to look in the item array

long ll_row, ll_max
menu lmenu_return // the return value
setNull(lmenu_return) // default to null

// Loop through the item array

ll_max = upperBound(amenu.item)
for ll_row = 1 to ll_max
// Call myself for every element in the array

lmenu_return = mf_findMenuItem(amenu.item[ll_row], as_name)
if isNull(lmenu_return) then
// It was not a match, look in the next element
else
return lmenu_return // We got a match, time to unwind
end if
next

// No match in the entire item array, sorry about that.
return lmenu_return

The comments should make this fairly obvious but I'll walk you through it anyway.

We have two arguments. One is the menu that we would like to search. Remember, it has its own item array. First we check to see if this menu item is a match. If it is then we're done. If it's not then we have to search every element in the item array for a match.

That's basically all there is to it.

Insert Security Rows in the Database
Next we need to insert the two rows in the database that will let us have the effect we want. One row has to set the ‘Test 1' menu item to read-only and the other sets ‘Test 2' to invisible.

Rows for our security table

INSERT INTO "security" 
( "login_name",  
"application",  
"item_type",  
"item_name",  
"priviledge" ) 
VALUES ( 'dba',  
'security_test',  
'menu',  
'Test 1',  
'R' )  ;

INSERT INTO "security" 
( "login_name",  
"application",  
"item_type",  
"item_name",  
"priviledge" ) 
VALUES ( 'dba',  
'security_test',  
'menu',  
'Test 2',  
'I' )  ;

Implementing the Menu Security
Now we inherit a window from w_root and we give it the m_main menu. Then we go to the open event of w_root and put in the following code:

W_main.open

m_root lmenu
lmenu = this.menuid
lmenu.mf_loadsecurity("dba" , "security_test" )

This should be pretty self-explanatory. You might not be aware of what the second line means. The menuid property of any window is the menu object that is assigned to that window.

You might wonder why I would add this code to the open event and not the ue_postOpen. The answer lies in the functionality of the open even and ue_postOpen.

The open event happens before the drawing of the window. The ue_postOpen is posted in the ancestor window (w_root) and therefore happens after the window is drawn. In our case we don't want the window to be displayed until after the security happens so this is one of the very rare instances where we want code in the open as opposed to the postOpen events.

The Final Touch
Lastly we have to add the code for the Application open event to fire everything off.

Application open event

// Profile EAS Demo DB V115
SQLCA.DBMS = "ODBC"
SQLCA.AutoCommit = False
SQLCA.DBParm = "ConnectString='DSN=EAS Demo DB V115;UID=dba;PWD=sql'"
connect using sqlca;

open(w_main)

Of Course There Is Always More
If you think about the menu security you will soon realize that we don't allow for duplicate menu texts. Only the first match to a text will be found. We could change this by comparing the menu name rather than text. That would be something like m_root.m_file.m_new.Test1. That won't be a hard change if you want to do it yourself.

You could also use this metaphor to implement window level security. Using the same table then looping through the control array for the window in the open event looking for window controls that are in the security table for the user name and application. That should be simple enough for you now that you know how to do it.

NOTE: The code in this article uses my proprietary tools.pbl. You can reproduce it or you can write me asking for both the source of this article and the tools pbl as well. My e-mail address is at the bottom of the article.

Also, all the data for the application comes from the sample database that comes with PowerBuilder. That is the database that almost all of my readers have. I have had to expand the table though to support the needs of this article.

More Stories By Richard (Rik) Brooks

Rik Brooks has been programming in PowerBuilder since the final beta release before version 1. He has authored or co-authored five books on PowerBuilder including “The Definitive DataWindow”. Currently he lives in Mississippi and works in Memphis, Tennessee.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.