Home > Support
DataWeb User's Guide
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.
to Create or Edit a Script
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.
to Run a Script
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
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.
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:
the function with the permissions of the Administrators
the function with the permissions of the Staff
the function with the permissions of the Members
the function with the permissions of the Guests
Run the function with the permissions of the
current user's security group
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)
var mem = Members.getMemberFromEmail(email_string);
if (mem == null)
response.write("You've been added as
a member of "
+ request.getServerName() + "\n");
response.write("We were unable to add you
as a member of "
+ request.getServerName() + "\n");
Limits on Script Execution Permissions
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
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
to Import a Class
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.
to Run Methods of a Class
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.
More Complex Example
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.
Security and Scripting
The DataWeb security model is powerful, but it can get
complicated. To minimize hassles for yourself, consider
the following pointers:
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
judicious when assigning Design, Set Security, and
Change Members permissions to a group. Consider whether
those permissions are truly necessary for the group.
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.