Secure by User or Session ID
After you have implemented Sign on Security (see here), you may want to control who can see which records. For instance, if I have an order history table for five customers, each customer should only be able to see their own records. Rather than making five separate applications, we can create one and implement security on it.
Of course, in all cases we can utilize Row Level Security (learn more about this here), however if the user's USERNAME (or Session ID) is listed in the table, we can utilize a feature of our servlets called "Secure By". When active, the User Name field (specified by being the first key field within your application), is compared in the SQL statement to your login. Only matching records will be shown.
To set up, only a few things need to be in place.
- The first field listed in Field Settings must be the UserName or Session ID field.
- You must be utilizing the mrc built in Sign-on logic (mrcSignon2).
- You must activate the Secure By Feature. To do this, please see the following information:
- Compile your application as you normally would (making sure to first sequence by the USERNAME field).
- Next, go into Application Properties, and click the "SQL Statement" tab.
- Then, find the "Secure Application by" option, and choose "User Name".
- Click Save.
Here is a screenshot before Secure By security was implemented:
And here is the after shot:
Since I logged on as HURCKES, I can only see "Hurckes" records. Further, if I turn on debug, you can see the SQL statement that was generated:
WHERE T01."USER"='HURCKES' was added because the Secure By function was implemented.
Note: The end user has no way to modify this SQL statement.
- The same functionality is available for Session IDs. A session ID is a 40 character field given from your browser that serves as a unique identifier and can be very useful when tracking users between multiple screens. An example can be seen in this post on our Tech Blog regarding creating Shopping Carts, found here.
- In my example my USERNAME field happened to be "USER". In your applications, the field can be any name so long as it is the first key field.