The username must be a sequence of alphanumeric characters (and "_"). Usernames are case sensitive. However, usernames which begin with "Guest_" are considered guest entries and will be deleted if no legal ticket is associated with them. (Please see Public Access for more information.)
The institution column, which is optional, contains logical divisions to which a user is a member (for example, different schools for a academic application or different teams for a game). The pair (username, institution) should be unique for each user. Therefore, users in different institutions can share the same username. If not used, the institution should be set to '0' (the empty string is not used due to some databases interpreting the empty string as NULL).
The password column contains the password for the user. If SteelBlue was compiled with the NO_CRYPT flag, then the password is stored in the database in clear-text. If not (i.e. the crypt function was available), the password is stored in the database using one-way encryption.
insert into AuthUsers (username, institution, password)
values ('admin','0','zdYu5Ni2DKchs');
insert into Groups (username, institution, grp)
values ('admin','0','admin');
To encrypt your own password (and test the crypt ability of your
installation), choose "Encrypt Password" from the welcome page of the
standard distribution BasePages.
A login form submits to your steelblue executable with the "POST" method and contains at least two input boxes: "username" and "password". A third input box "institution" is optional. For example, the following is a simple login page which submits to the executable "/cgi-bin/steelblue" and prompts for the username and password:
<HTML>
<HEAD><TITLE>Login</TITLE></HEAD>
<BODY>
<CENTER>
<FORM ACTION="/cgi-bin/steelblue" METHOD=POST>
<TABLE>
<TR><TD>
<B>Username:</B>
</TD><TD>
<INPUT NAME="username">
</TD></TR>
<TR><TD>
<B>Password:</B>
</TD><TD>
<INPUT NAME="password" TYPE="password">
</TD></TR>
<TR><TD ALIGN="center" COLSPAN=2>
<INPUT CLASS=BUTTON NAME="submit" TYPE="SUBMIT" VALUE="Login">
<INPUT CLASS=BUTTON TYPE="reset" VALUE="Clear">
</TD></TR>
</TABLE>
</FORM>
</CENTER>
</HTML>
The file "login_failed.html" in the BasePages directory of the standard distribution is appropriate for using as a simple login page that submits to "/cgi-bin/steelblue". So for the default SteelBlue installation, setting the configuration option "login-screen" to "login_failed.html" and "login-object" to "Login" will cause a login screen to appear when accessing the steelblue executable for the first time.
Since the user has a unique username and institution entry, the Swap
can be used to temporarily hold information for the length of the
session, and the Groups table can temporarily assign guest users to
groups (see Group Based Security).
Tickets expire after the number of hours given in the "SessionTimeout"
configuration parameter (which defaults to four hours). At the
beginning of every SteelBlue execution, expired tickets, associated
guest users, and their Swap entries are deleted from the database.
Group Based Security
Many applications give special abilities to sets of users. For
examples, administrators are usually given the ability to create
and modify users. These sets of users are called groups, and
group-based security is supported in SteelBlue.
Adding a User to a Group
Associating a user with a group is done by adding an appropriate row
into the Groups table. For example, the following adds the user
"butch" in institution "0" to the group "editor":
insert into Groups (username, institution, grp)
values ('butch','0','editor');
Users may be in multiple groups by having multiple rows in the Groups
table. However, the "Create/Edit Users" utility in the default
BasePages assumes that every user is associated with exactly one
group.
Checking Group Membership
Group membership can be checked with the group Eval function. For example:
<if bool="group('admin')">
Hey, you are in the admin group!
<else>
You're not an administrator...
</if>
For the best security, we suggest that you check group membership in
both the HTML and CHECK sections of a form that grants special
abilities to particular groups.
If a page does not match any entries, then all users are allowed to
access it. Please note that the AreaAccessTable configuration option
must be set for Area Access to take effect.
If a page is not listed in the "dest" column, then all pages are
allowed to precede that page. Please note that the ScreenAccessTable
configuration option must be set for Screen Access to take effect.
Area Access
With the AreaAccess table, access to the HTML section of a page can be
restricted to particular groups. This is done by creating an entry
for each group in the AreaAccess table where the path column contains
a case insensitive substring of the path to the page (relative to
BasePages) and group is the name of the group. Using a substring in
the path column allows whole directories to be restricted to a
particular group. Case insensitivity is required to support Win32
filenames. For example, the following restricts all the pages in the
"admin/" subdirectory of the BasePages to the admin group:
insert into AreaAccess (path, grp)
values ('admin/','admin');
Screen Based Security
With the ScreenAccess table, the sequence of pages that users take can
be restricted (i.e. the CHECK and ACTION section of one page can be
set to have to precede the HTML section of another page). This is
done by creating entries (in uppercase) in the ScreenAccess table for
the source page in the "source" column and the destination page in the
"dest" column. Uppercase is required in order to support Win32
filenames (which are case insensitive). The path to each page
(relative to the BasePages directory) must be used in the entries. Do
not include the beginning slash in the path. For example, the
following allows the 'user_edit.sb' page to be accessed only from the
'user_select.sb' page:
insert into ScreenAccess (source, dest)
values ('user_select.sb', 'user_edit.sb');