Search these areas:
Help
Support Forums
Product Info



-Introduction
-DataWeb: What's New
-Creating an Application
-The DataWeb Designer
-Application Management
-Data Tables
-Data Tables
-Views
-Templates
-Components
-Data Analysis
-Members
-Security
-Importing
-Exporting
-FTP
-JavaScript
-Object Model
-Full-Text Search
-Domain and Email Hosting
-HotBlock Modules
-Account Management
-Glossary
-New Responsive UI Module





DataWeb Help
Support Forums
Tutorial
Script Library
Knowledge Base

Home > Support

Script Library

  Filter a view based on a custom field in AddressBook, e.g. "Department"
 
  chubbard posted this script:
  Often the security requirements of an application are more specific than can be handled directly by the built-in groups and pre-defined roles that exist in Westside today.  An example is wanting members to only be able to see the records that belong to their department (while admins can see all records).  You can think of this example as a combination of "custom groups" and "row-level security". 

It's very easy to handle this requirement in script.  The solution is to programmatically set the Preset Filter property of a view based on the current user.  To make the security more manageable, the preset filter property in the view should call a script file to compute its value.  For example, a file named Permission.ws has a function

function getFilter(field)
    {
    // Admins can see anything
    if (User.isAdmin())
        return("");

    var rs = Table.select("AddressBook","Dept",
            "UserName='" + User.name + "'");
    rs.next();
    return(field + "=" + rs.Dept);   
    }
   
Then in the view (at the start of the body) you include a line to create the class:
<BODY>
     <!--#
         var p = Classes.import("/Permissions.ws");
     #-->
...

and then the Preset filter property on the dataregion in the view is

       #p.getFilter("DeptID")#

The security rules in Permissions.ws can be as sophisticated as you need them.  They can be driven off of custom fields in the AddressBook and/or any other table you choose.

In the end you have centralized, customized security rules enforced on data access. 

Note:  If  a user can't see a row, he also is not given an Edit button or a delete checkbox to modify it.  In many situations this is sufficient security to prevent users from one department from modifying records belonging to another deparment.  If the data is highly sensitive, and the views are made accessible to users who might not be trusted, you should also protect the data against a user who deliberately POSTs to the view and edits/deletes a record that they can't see but somehow know exists.  Protecting against this is easy, put a check in the BeforeUpdate and BeforeDelete event handlers  that calls a simillar function: 

function checkDept(field)
    {
    if (User.isAdmin())
        return(true);

    var rs = Table.select("AddressBook","Dept",
            "UserName='" + User.name + "'");
    rs.next();
    if (record[field] != rs.Dept)
          return (false);
   
    return (true);
    }
 
Affiliate | Partner | Terms of Use | Privacy Policy | Contact Us | Pricing | Bring DataWeb In-House    
DataWeb, 720 North 10th Street, A #145, Renton, Washington 98057 *425-583-5970* Fax 484-770-4706* Email Us