Securing Scripts

DataWeb Script provides a flexible and powerful means of building web applications. With this flexibility, however, comes the risk that a malicious user could take advantage of the DataWeb Platform's scripting capabilities to access or change private data. To protect your data from this possibility, DataWeb has developed a sophisticated security model for controlling access to scripts.

Scripts can exist in a data class, in a DataWeb Script class, or in a view. The security model applies no matter where the script resides.

Permissions to Create or Edit a Script

In order to create or edit a script, a user's security group must have Design permissions on the folder that contains that script. By default, only the web owner and the Administrators group have Design permissions on the folders of your web.

Permissions to Run a Script

The DataWeb Platform checks security settings for each operation that a running script performs. Two factors determine whether these security checks will be successful for a given operation. The first is the security settings on the folder that contains the script file. The second involves the permissions that are in effect when each script operation is executed.

Folder Security Settings

Whether or not a user has permission to execute script in a given file is first determined by the security settings for the folder that contains the file. In order to execute script in a file, a user must belong to a group that has Browse Files permissions on that folder.

By default, all of the built-in groups (except for the Anonymous group) have Browse Files permissions, so if you don't alter the default security settings, all users will be able to execute script files. If you change the security settings for a folder, note that the Reader role is the minimum security role with Browse Files permissions.

The operations script can perform are also determined by the executing user's permissions in the folder containing the script. For example, a user must belong to a group with Edit Records permissions in order to execute script that edits records in a web.

Script Execution Permissions

There may be cases in which it's useful for script to run with permissions that are different from the current user's. For example, you may want to allow anonymous users to sign themselves up as members of your web. Currently the only way to do this is to write script that the user will execute in order to add themselves.

In order to permit script to perform an operation that the executing user's permissions do not allow, you can define script functions with a qualifier that specifies the executing permissions group for the function.

The following table describes each of the qualifiers available for altering the execution permissions of a function:

Function Qualifier	Description
asAdmin	Run the function with the permissions of the Administrators group
asStaff	Run the function with the permissions of the Staff group
asMember	Run the function with the permissions of the Members group
asGuest	Run the function with the permissions of the Guests group
asUser	Default. Run the function with the permissions of the current user's security group

Note that although these qualifiers form part of the function definition, they apply not to the function itself but to operations performed by the function. Any group with Browse Files permissions can run any function, but they may not have permissions to perform every operation that the function attempts to perform.

The following function adds a user as a member of a web. The function is defined with the asAdmin qualifier, which ensures that the function will run with the same privileges as the Administrators group. Because the Administrators group has permissions to add new members, this function will add the new member.

public asAdmin function AddMeAsMember(email_string)
{
  try
 {
 var mem = Members.getMemberFromEmail(email_string);
 if (mem == null)
   {
   Members.add(email_string, "members");
   response.write("You've been added as
   a member of "
 + request.getServerName() + "\n");
   }
 }
  catch (err)
 {
 response.write("We were unable to add you
 as a member of "
 + request.getServerName() + "\n");
 }
}

Important Limits on Script Execution Permissions

After reading the previous section, you may be wondering what prevents any user from writing a function to run with administrative privileges and performing operations that they wouldn't have permission to otherwise. Any user with Design permissions can create or edit a function like the one in the previous example, whether or not they actually have permission to add members to the web, and there's currently no way for the system to know which user created or edited a particular script.

For this reason, the DataWeb Platform places an additional restriction on executing script. Before a function is run, the system checks the permissions of all groups that have Design permissions on the web, since any user with Design permissions could have edited the function. If the function tries to perform an operation that the group with the least permissions does not have permission to do, then the operation will fail.

For example, suppose that you've granted Design permissions on your web to the Members group, by assigning them the security role of Designer. This means that users who belong to the Members group can modify script in data classes, views, and DataWeb class files. However, users in the Members group don't have permission to add or remove other members from the web. Suppose you then write a function like the previous example, to be run with asAdmin privileges. Before the Members.add() operation is executed, the DataWeb Platform checks to make sure that the script file could not have been edited by someone who does not have permissions to modify membership. In this case, the system would determine that the file might have been edited by a user in the Members group. Because the file might have been edited by someone without the proper permissions, the function will run with the permissions of the Members group, which are insufficient to add a new member.

This behavior is designed to be conservative to protect your data. However, it can get confusing. For example, suppose you, as the owner of the web, were the one who actually edited the function to add new members and to run with administrative privileges. If you've also given the Members group Design permissions on the web, your function will generate a runtime error at the point that it reaches the Members.add() call. This runtime error will happen even for you, because the system recognizes that the script file could have been edited by someone who didn't have permission to add new members (even if it was edited by someone who does have the proper permissions). No matter who you are or what your permissions are, when you're running a function, your permissions are those of the group with the lowest permissions that include the ability to edit the script file.

The default security settings for the web grant Design permissions only to the Administrators group and to the web owner. With these settings, the function in the previous example will run with administrative privileges, for you and for anyone else who has permission to run it (that is, anyone who has Browse Files permissions on the directory containing the file). The function runs without error because it could only have been edited by someone who has permissions to add members.

The Security tab for the web root or a folder indicates the highest privileges with which script in that folder can run. You'll see a list of groups on this page; with the default security settings, only the Administrators group appears on the list. If you assign Design permissions to the Members group, it will also appear on the list. The listed group with the least permissions determines the maximum privileges with which functions will run.

When the execution group - the group with whose permissions the function is running - does not have sufficient permissions to perform a particular operation, an exception is thrown. This exception can be caught and handled like any other exception.

Permissions to Import a Class

In order to import a class and call its methods from within another function, the group under which the script that's importing the class is running must have Browse Files permissions on the folder that contains the class. For example, suppose you have a function in a folder that runs with the permissions of the Members group (because the Members group has Design permissions in that folder). When that function attempts to import a class in another folder, the system checks that the Members group has Browse Files permissions in that folder. If it does, the class will be imported successfully. If it does not, then the class will not be imported, and the import() method of the Classes object will return null.

Permissions to Run Methods of a Class

Once a class has been imported, you can call methods of that class. When you call a method of a class, your code is no longer running in the function that called the method; it is now running in that class. If the class that you've imported is in a different folder than the class containing the calling function, then the permissions with which the method runs are determined by the security settings on that folder and by the qualifier on the function. If there's no qualifier specified, then the function runs with the default asUser qualifier.

Once a method inside of the imported class is running, the security settings on the class containing the calling function are no longer relevant. Only the security settings on the imported class determine whether the script can successfully perform each operation that it attempts.

A More Complex Example

Let's consider an example that is more complicated, but demonstrates a common scenario that could cause you difficulty. Suppose that you have an Admin data table, which you want to make accessible to the web owner and the Administrators group only. You might be tempted to assign the No Access role to the Staff, Members, and Guests groups on the Admin folder, to prevent anyone else from having access. Suppose you then write a function named InsertAuditRecord() to insert a record into the Admin table from the Utilities folder, where the Staff group has the Designer role and thus has Design permissions. No matter who runs the InsertAuditRecord() function, it will always fail, because the function will run with the permissions of the execution group, and those will be the permissions of the least group with Design permissions. Even when the web owner runs the script, it will run with the permissions of the Staff group, which are not sufficient to insert a record into the Admin table if the Staff group has the No Access role there.

A simple way to remedy this situation is to remove the Staff group's Design permissions, so that the function will run with administrative privileges.

A somewhat more complicated approach is to assign the Reader role on the Admin table to the Staff group. Create a class in the Admin folder, and add your function to that class, defining it with the asAdmin qualifier. Then import that class from the Utilities folder. Because the Staff group now has the Reader role on the Admin table, the script running in the Utilities folder will be able to import the class. And because the InsertAuditRecord() function is defined with the asAdmin qualifier, and only the Administrators group has Design privileges on the Admin table, the InsertAuditRecord() function is guaranteed to run with administrative privileges, and will insert the record into the table. The drawback to this approach is that the Staff group will then also have permissions to read the data in the Admin table.

Troubleshooting Security and Scripting

The DataWeb security model is powerful, but it can get complicated. To minimize hassles for yourself, consider the following pointers:

•	Modify security settings for just one directory at a time. Test your script and make sure everything works as expected. When you're confident that your settings are correct, repeat the process for another directory. It may take longer to design your web in this manner, but it can save you difficult debugging problems later.
•	Be judicious when assigning Design, Set Security, and Change Members permissions to a group. Consider whether those permissions are truly necessary for the group.
•	Keep in mind that the permissions in effect when a function is running do not necessarily correspond to the permissions that the current user normally has. The permissions in effect when a function is running are those of the group with the least permissions that include Design permissions - that is, the group with the least permissions who could have edited the script. Even the web owner or an administrator may be restricted by this limitation.