Security and Privileges

Security and Privileges

WODA distinguishes between users and groups of users. Access to individual actions within WODA is still based on a group to which a user belongs to. Three levels of security can be assigned to a WODA table:

1. Minimal; groups only. No groups are defined by the administrator. WODA creates three groups: admin, friend and guest. Admin can do anything. Guest can do anything except access the admin actions or order agent searches. Friends are guest that chose to register.
2. Custom; groups only. Other groups are defined in '$WBB{groups}' and access rights of the groups are defined in '$WBB{rights}'.
3. Custom; groups and users. A separate WODA table for user information is set up. '$WBB{userTable}' should be set to point to it. Other '$WBB{user*}' settings are used to define to which group all these users belong (unless their group is defined in their '$rec{group}' and on how to evaluate if the user is allowed to use the database.

Defining groups

Groups are defined in '$WBB{groups}' field. This field contains a table with fields: groupname, IP address and password:

joe             193.8.9.34     password1
company         we.com$        password2

WODA starts at the top of the table and looks for a match of address and password (if defined). When a match with the supplied information is found this is the group. There are two default users, admin and guest. Admin's information is part of the WODA setup!

Passing group (or user) and password information to WODA

There are three ways to do this:

1. By IP address of the client workstation. It will be matched against second column above.
2. By passing username and password via URL. See above how to do this.
3. By logging in using the login button in the footer of all WODA pages and passing this information later via a cookie.

WODA first tries to interpret the username as username and match it against the users in the '$WBB{userTable}' database. If this fails, the username is interpreted as groupname. Beware that usernames override the groups, except groups guest and admin!

Allowing/denying actions

Users may be allowed or denied actions in the database. Actions specified in the URL before the ? and after the script name. Actions may be allowed or denied for some users in a table defined in '$WBB{rights}'. This field is a table like:

allow   joe     ^Search
deny    .*      ^Search

In the first column is the word 'allow' or 'deny'. In the second is a pattern which will be matched against current user's group and in the last the pattern matched against the requested action (as shown on the URL). The program will start at top and process lines as long as it does not find a match in both user and action. The it will either allow or deny it. If there were no matches, the action is allowed. Above only joe and admin (of course) will be allowed to search.
Read only database would have rights like:

$WBB{'rights'} = 'deny .* ^Edit|^Delete|^Add|^Adm';

Note that if the rights field is defined, Adm* actions have to be disabled as well.
The actions that are not allowed will not show in menus.

Denying access to records

Generally, every record entered into a WODA database is immediately available to all users of the database and found in all searches. Administrators can set up a database in such a way that they clear the record before it is available to others or that they can simply filter out some records which contain e.g. obscene content.
'$WBB{filter}' defines and expression which is silently appended to every query string. So that if you put there -sex, no records which contain word sex will be found in searches. If you set

$WBB{'filter'} = "+qwerty"

only records which include string qwerty will be found. Administrator should use 'sees' and 'edits' field options so that only he/she can put values into a field which only he/she sees and is allowed to edit.

Allowing/denying access to the field

In the '$WBF{field,sees}' a pattern of users is defined, which can see the value of the field. In '$WBF{field,modifies}' a pattern of users is defined which can change the value of the field. If undefined, anyone has access.
Warning: Users are still able to search by fields they do not see. They will not be seen in WODA generated printouts, but will be displayed in the '$WBB{format;DEFAULT}' expressions if explicitly required.