This page provides basic information to assist CSULB users who wish to use scripts or advanced Apache features.
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:
#!/usr/bin/perl
or:
#!/usr/local/bin/perl
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. Instructor and staff may also use vanilla.csulb.edu for that purpose.
To call your CGI script, use a URL in the following format:
http://www.csulb.edu/~username/cgi-bin/scriptname.cgi
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.
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 csulb.edu, 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="http://www.csulb.edu/cgi-bin/formmail.cgi" 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. "youracct@csulb.edu"). Moreover, the recipient address must consist of a CSULB email account name followed by "@csulb.edu". 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="acct@csulb.edu">
You may also include hidden fields to specify:
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.
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.
To restrict access only to computers on campus (including the campus dial-in lines), use this .htaccess file:
AuthType Basic
AuthName "CSULB IP Only"
<Limit GET
POST PUT DELETE>
order deny,allow
deny from all
allow
from 134.139
</Limit>
Note that if you use an AuthName of more than one word it will need to be surround by quotation marks.
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
<Limit GET
POST PUT DELETE>
require valid-user
</Limit>
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:
comein:kisDCqnu4f3so
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:
http://www.csulb.edu/cgi-bin/encryptTo 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://ldap.csulb.edu:389/o=csulb?uid?one?(uid=*)
require valid-user
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://ldap.csulb.edu:389/o=csulb?uid?one?(uid=*)
require user
CAMPUS-EMAIL-HANDLE
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 (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 (/divisions/aa/academic_technology/itss/contact/).
