Scripting Support Page

Scripting Support

This page provides basic information to assist CSULB users who wish to use scripts or advanced Apache features.

CGI Scripts
Forms on the Web
Access Control: Restricted Web Pages
Server Side Includes

CGI Scripts

The campus webserver permits running of CGI scripts through CGIwrap, which assures that your scripts run under your own account. Although other languages could potentially be used, just about everyone uses Perl for CGI scripts. You may either import scripts that you find on the Internet or write them yourself. To enable them to run, you must create a "cgi-bin" directory under your htdocs directory and make sure that the permissions allow public read and execute access but not write access. Fortunately, that is the normal default for directories.

Place your CGI scripts inside your "htdocs/cgi-bin/" directory and set their permissions to the same values (owner: read, write, execute; group: read, execute; public: read, execute, ie. Unix permission code 755). You may also place the scripts in subdirectories of your "cgi-bin" directory if you prefer to organize them that way.

Use the ".cgi" extension on the name for your script, eg: "takeform.cgi".

The first line of your Perl CGI scripts should be either:




The syntax for this line is strict; do not include anything else on this line, not even a blank character at the end. It's generally best to check the syntax of your script on your own system with your local version of perl before trying it out as a CGI. Faculty and staff may also use for that purpose.

To call your CGI script, use a URL in the following format:

Use your own account name after the tilde (in place of "username"). Typically you would include this URL as the action to be taken by a form that submits data to the CGI script.

Pitfalls to Avoid

  • To guarantee that your script gets transferred properly, use ASCII text mode to upload it with FTP instead of Binary mode. The most frequent cause for script failures is transfer of extraneous characters from the PC by use of Binary FTP mode.
  • Make sure that your permissions are correct, both on the script itself and on the directories above it. In particular, scripts will be rejected if any of these has public write permission (which of course would be a very bad idea anyway).
  • Only use plain ascii text files for CGI scripts. Word processing documents will need to be exported into plain text before being uploaded.
  • Be sure to include the ".cgi" extension for your script name. If you omit the extension, your script will not run; instead a listing of the script will be displayed.

Forms on the Web

Although creating forms for the web is easily accomplished with most any HTML editor (eg. Dreamweaver, GoLive, etc.), posting the data from the form requires a program on the webserver to process the data. We have one general purpose form processing script that mails the results to a selected account at, named "formmail.cgi". This arrangement uses hidden fields built into your form to pass along required configuration information to the script which is called with the "action" attribute of your "form" tag. For example:

<form name="myform" action="" method="POST">

is typical of form tags which use our "formmail.cgi" script.

You must include a hidden field specifying the "recipient" email address (eg. ""). Moreover, the recipient address must consist of a CSULB email account name followed by "". Attempts to use off-campus or multiple recipients will be rejected. To route the output to multiple recipients, set up a CSULB email alias pointing to the list of recipients. This hidden field would typically look like:

<input type="hidden" name="recipient" value="">

You may also include hidden fields to specify:

  • "email": the email address that the mail will appear to be sent from, and/or
  • "subject": the subject line that will appear on the email message.

These fields may even be included as text fields on the form if you wish to request that your form users provide this information about themselves.

If you include a hidden field called "required" with a comma separated list of other form field names as its value, the script will reject postings which omit data from any of these required fields. You may also include hidden fields to specify common style characteristics of the acknowledgment page such as "bgcolor", "text_color", "link_color", "vlink_color", etc. If you need some form processing that is not specifically offered by "formmail.cgi", then you may build your own CGI script to process the form. Even more complex form handling by database applications is possible, but requires that you obtain access to a web database server.

Access Control: Restricted Web Pages

You may control access to your web area on the CSULB server in several ways. By default, all pages are open to anyone. If you wish to restrict access to some (or all) of your pages, you may do so with an access control file. This file, named ".htaccess", should be placed in the directory where the protected pages reside. Thus if you place it in your base "htdocs" directory, you'll establish access control over your entire website.

However, most people prefer to place restricted files down in a subdirectory, so that their main pages remain open to the world. In either case, the ".htaccess" file specifies access controls to be used for all files in the directory where it appears and any subdirectories below that qone (unless they override it with their own ".htaccess" files).

You proceed by creating a plain ascii text file (not a formatted Word document) and put it in the appropriate directory with the name ".htaccess" (note the leading period on the name). Most often you'd build the file on your PC and ftp it (use ftp software such as "WS_FTP" on your PC or "Fetch" on your MacIntosh) up to the directory. Three typical choices are illustrated with examples: CAUTION -- Do not type any extraneous characters (including spaces) in front of or behind any line in these example files.

Access on all Campus Computers

To restrict access only to computers on campus (including the campus dial-in lines), use this .htaccess file:

AuthType Basic
AuthName "CSULB IP Only"
order deny,allow
deny from all
allow from 134.139

Note that if you use an AuthName of more than one word it will need to be surround by quotation marks.

Access to users without a Campus Account

To require a specific account and password (chosen by you, and given only to those you wish to let in), use this .htaccess file as a template:

AuthType Basic
AuthName Restricted
AuthUserFile /home/az/jdoe/authfile
require valid-user

In this case, you'll need to substitute the path to your own home directory (instead of /home/az/jdoe). You may either keep the file name "authfile" or choose another. You'll also need to create a file under that name in your home directory to specify the desired account and password to be used for access. Actually, you may include several lines of accounts and passwords if you're willing to bother keeping track of them.

A typical "authfile" might look like:


Since the password must be encrypted in order to be put in the file, you'll need to carry out the encryption by filling out this form:

Access to Users with Campus Accounts

To require an account and password valid on the CSULB network (including our extranet), use this .htaccess file:

AuthType Basic
AuthName "Campus Accounts Only "
AuthLDAPURL ldap://*)
require valid-user

Access to Users with Specific Campus Account

To require an account and password valid on the CSULB network (including our extranet), use this .htaccess file:

AuthType Basic
AuthName "Campus Accounts Only "
AuthLDAPURL ldap://*)

In this case, you'll need to substitute the text CAMPUS-EMAIL-HANDLE to your own account(s)

Multiple campus email handles are separated by spaces.

Of course you may use more complex .htaccess files if you're familiar with the format and need something that reaches beyond the examples presented here.

Server Side Includes

Server Side Includes (SSIs) are allowed, but require the calling page to have the extension .shtml instead of .html. Typical syntax for includes would look like:

<!--#include virtual="includes/includedpage.html" -->.

Here the section "includes/includedpage.html" identifies the path to the page to be included. If it is in the same directory, just use the file name, otherwise provide a path to the file (eg. the "includes" directory listed above.

Note that the <!--#exec ...--> command is not allowed for security reasons. Nonetheless, you may use CGI or PGP scripts as an alternative if you need to generate dynamically executable pages.


The scripts provide the basis for managing personal webpages. For additional requests, please contact David Bradley (