Pretest Files

Since I can’t get myCourses to let me upload files, here’s a Zip archive of the image files (1.5MB) for use in the pretest.

CSS In-Class Exercise from 320

This is the CSS exercise given to students in the 320 class last quarter.

CSS-ICE.doc

In-Class Exercise: Installing Movable Type

1) Telnet (or secure shell) to grace, and use pwd to find the full path to your home directory (you’ll need this later, so write it down). Mine is /users/rit0/g1/ellics, but yours will be slightly different.

2) If one doesn’t already exist, create an .suexec file in www directory. (The presence of this file allows the web server to run CGI programs as “you,” so that you don’t have to give write permissions to the whole world.) The easiest way to create the file is to use the “touch” command.

3) You’re going to need three directories—one in your home directory to hold the database files, and two in your www directory for the movable type program files and the blog itself. In the examples below, the database directory is called db, the movable type program directory is called mt, and the blog directory is called blog. You can call these whatever you want. The permissions on all three directories must be set to 755.

(If you use the example directory names, the path to log into your blog for editing and configuration would be http://www.rit.edu/~yourid/mt/ , and the path to read your blog would be http://www.rit.edu/~yourid/blog/)

When done, log out from grace.

4) Download the full version (with libraries) of Movable Type, and decompress it locally with unstuffit or winzip.

5) Edit the mt.cfg file using a good text editor (e.g. BBEdit or UltraEdit). Make sure the program is set to save the files with UNIX line breaks, to avoid problems when uploading. (More detailed information on the configuration file can be found in the Movable Type installation documentation, on their web site. This is an abbreviated, RIT web server version of the instructions).

• change the CGIPath variable to be http://www.rit.edu/~yourid/mt/ (if you chose a different name for the movable type file directory, use it here)
• change the DataSource line to show the full directory path to your db directory (e.g. /users/rit0/g1/yourid/db), substituting your path from step 1, and the name you gave your db directory
• Uncomment the following lines in the file by removing the # from in front of them.

DBUmask 0022
HTMLUmask 0022
UploadUmask 0022
DirUmask 0022

6) Use an FTP program to upload all files and directories in the distribution directory to the movable type directory you created. Most FTP programs will properly set the directories to 755 and the files to 644, but you probably want to check to make sure that’s the case for the mt directories.

7) Using your FTP program, or a telnet/secure shell connection, change the permissions on the .cgi files to make them executable (chmod 755 *.cgi)

8) Open a browser and run the mt-check program to test the installation:
http://www.rit.edu/~yourid/mt/mt-check.cgi

If mt-check.cgi is successful, run the mt-load program to initialize the software
http://www.rit.edu/~yourid/mt/mt-load.cgi

(Substitute the name of your movable type directory if you didn’t use mt)

If mt-load runs properly, delete the file so it can’t be re-run.

9) Use a browser to go to http://www.rit.edu/~yourid/mt/mt.cgi and log in with the default values—user Melody, password Nelson. Immediately edit your profile to change the user name and password to what you want. (The user name will be what shows up on your posts, so choose something you’d like to be “public”.)

10) Choose “Manage Weblog” for the default weblog that was created, and then select “Weblog Config” from the menu on the left.

11) On the first config screen, you need to enter the UNIX path to your blog directory, and the URL to the directory; then add “archives” to the end of each for the next two fields. It should look much like the example below, but with your user ID and path substituted for mine.

12) Now rebuild your weblog, and test it by clicking on the “View Site” button at the top of the screen.

In-Class Exercise: Assessing Accessibility

1. Use Cynthia Says to evaluate at least two of your own web pages (with at least one of those being on your Grace account). If you don’t have a web page of your own, or if the server is not accepting URLs from rit.edu, review a page that you visit frequently. Make note of all of the priority 1, 2, and 3 problems identified.
2. If you reviewed your own web page, fix the Priority 1 problems. Remember that to pass the W3C recommendations, you must not have any Priority 1 problems. (You may find it helpful to use the WCAG checklist.)
3. After you’ve fixed your Priority 1 problems, look at the other comments in the report provided. Your efforts should now be directed towards fixing any Priority 2 problems. Finally, Priority 3 problems may also be fixed to provide maximum accommodations.

Post a comment to this entry that describes what problems you found on the site that you visited. If it was your own site, what level of accessibility were you able to achieve?

In-Class Exercise: Accessibility Simulations

1. Sign out a pair of headphones from the main computer lab (or use your own if you have some), and complete the tasks on WebAIM’s Screen Simulator.
2. Go to the Cognitive Simulator on the same site, and complete those tasks as well.
3. On the Vischeck site, provide a URL to a web page you’ve created, and see how it would appear to a person with color blindness. Try it with some of the web pages you frequent most often.

In-Class Exercise: CSS and Typography

Select a poem that you like from the “Verse” section of Bartleby.com.

Use CSS to modify the appearance of the poem.

Use Dean Allen’s Textile tool to generate valid HTML entities for punctuation, as needed.

When you’re done, upload the html file (and external CSS, if you used one) to your Grace account, and add an entry to your class weblog with a link to the page. If you don’t already have a category set up in your weblog for in-class exercises you should add one—that will let me view your in-class work easily at the end of the quarter when I’m assessing participation.

In-Class Exercise: CSS Positioning

Using the commandments example I provided in class, create your own page with CSS positioning and formatting. You can change as much or as little of the original as you’d like, but make sure that you’ve got a good sense of how the positioning properties work.

When you’re done, upload the file to your rit.edu web space on Grace, and add a weblog entry that points to it and describes what you changed and anything important you’d like to remember about how you created the page. If you don’t already have a category for in-class exercises, make sure you add one to your weblog, and assign it to this entry.

Files and Links for Javascript Exercises

Here’s a zipped archive of the files for today.

As a reminder, I asked you to put up your own versions of example 1, modify example 5 to use a switch statement and include a mouseout command for the graphics, and create your own drop down navigational menu using the simple menu from example 6.

These sites may be helpful, as well:

• DevGuru Javascript Quick Reference Guide
• Visibone Javascript Reference

Advanced Javascript & DHTML

In class, we’ll be working through the “Revenge of the Menu Bar” DHTML tutorial on BrainJar. This is one of a number of excellent tutorials on the site.

The BrainJar site also has excellent introductions to the Document Object Model and the DOM Event Model, which are useful if you’re going to write your own DHTML scripts.

As your CSS becomes more complex, you may find this CSS Selectors guide useful. There’s also this CSS Hacks page.

I’ve also linked to a number of DHTML and Javascript resources over on del.icio.us.

Server-Side Authentication: In-Class Exercise

Using Server-Side Authentication on Grace

The apache web server includes a program called htpasswd that allows you to create users and associated passwords for access restrictions on web directories. To password-protect a directory you need to do two things—first, use the htpasswd program to create a user and associated password in a world-readable file, and second, create an .htaccess file in the directory you want to restrict that references the password file.

If you’ve never created a password file before:

1. Create a directory in your home directory (not your www directory) to put the password file in.
2. Change the permissions on the directory you just created to 755
3. Make sure you’re in the directory you just created, and run the htpasswd program with the -c flag to create a new password file. You can name your password file whatever you’d like, but I suggest “hiding” it by starting the name with a period. You also must specify a user name to include in the password file when you first create it. (You’ll be prompted for a password for that username.)
   
   htpasswd -c password_file_name username
4. Change permissions on the new password file (whatever you put for password_file_name in the above command) to 644

If you have a password file, but want to add a new user to it:

1. Make sure you’re in the directory where the password file is located.
2. Run the htpasswd program without the –c flag, specifying the name of the existing password file, and the new username to add.
   
   htpasswd password_file_name username2

To restrict a web directory to a user specified in the password file:

Create a world-readable file called .htaccess in the web directory you’re protecting, with the following contents:

The AuthUserFile path should be the full UNIX path to your password file. (To find the path, change to the directory the password file is in, and type “pwd”.)

The AuthGroupFile should be left as /dev/null

AuthName is the label that will appear in the password prompt box; it can be whatever you’d like, but it cannot have spaces in it.

AuthType should be left as basic

Replace “username” in the last line with one or more users you’ve added to your password file using htpasswd. (The example uses two usernames.)

To restrict a web directory using DCE authentication:

On Grace, you can also use the .htaccess file to restrict access using DCE usernames rather than your own password file. You can only use DCE authentication through the secure (SSL) server, which means your page will have to be referenced using the https protocol, i.e. https://www.rit.edu/~abc1234/protected_directory/

To limit access to any RIT user with a valid DCE userid, use the following .htaccess syntax:

To limit access to only specific DCE user(s), use the following .htaccess syntax:

Server-Side Includes: In-Class Exercise

Look over Professor Vullo’s SSI Demo page, and/or the Apache SSI tutorial. Using those examples as a starting point, create a page that automatically shows the current date and time, and also includes a copyright statement (or some other fragment of text) taken from an external file in another directory.

Dynamic Sites & Basic CGI: Exercise

We need to start this exercise by making sure that you are able to install and run simple CGI programs on Grace written in Perl.

Setup: Create a subdirectory in your ‘www/409’ directory on grace called “cgi”. Remember to set the permissions so that the web server can read and execute both the contents and the program files. (Example: chmod 755 first.cgi)

Create the Program File: Using a text editor type in the following program, exactly as it appears below:

#!/usr/local/bin/perl -w
#
# Very simple cgi script that produces a web page as output
#
#  Your name here 
#  4002-409 - 2/04
#

#print the http Response Header before the html document
print "Content-type: text/html\n\n";  #notice blank line

#start the web page
print "<html><head><title>Generic CGI program</title> </head>";
print "<body> <h1>Generic Web Page</h1> \n";
print "<hr />\n";
print "stuff goes here\n";
print "<hr />\n";

#print the end of the web page
print "</body> \n</html>\n";

#end of this program

Install the Program File: If you created it on your PC or Mac, now upload it to your cgi subdirectory. Make sure you transfer the file in “ASCII” or “Text” mode and not “binary.” Then login to grace and view the file using a Unix text editor (like pico or vi). Make sure it looks okay (are the line endings in the right place? are there strange characters? if there are problems, you may need to save it in a different format, or upload it differently…)

What should the output of this program be? (Describe it in your blog entry?)

Make sure you understand what the program is supposed to be doing, so you will recognize correct output when you see it.

Test the Program File: Now, run the program directly on Grace, by typing this command at the prompt:

perl first.cgi

If all goes well, your program should execute. If it doesn’t, track down and fix the syntax errors until it runs.

Capture the output: To more accurately simulate how the web server will execute your program, use redirection of output to capture the output of your program into a text file. Try running your program a slightly different way:

first.cgi > firstout.txt

Notice we don’t have to use the “Perl” command at the command line.

Examine the output to make sure it is formed correctly by viewing the file firstout.txt. If everything looks okay, keep going. If not, see if you can find the problem.

Question to answer in your blog entry: What precedes the html in your output? Why would that need to be there?

Now you are ready to see if the program can be run as a cgi program.

Note: on some systems the program must end in a .cgi suffix regardless of the language in which it was written, in order to run as a cgi program. Grace is one of them. Some servers also require that all cgi files be placed in a “cgi-bin” directory in your main web directory, but Grace does not require this; you can place .cgi files anywhere in your web directory.

Test your cgi program by loading it in a browser (http://www.rit.edu/~yourid/409/cgi/first.cgi).

Create Another CGI Program: If that works, create a second cgi program—call it second.cgi. This second program will not produce a web page. All that it will do is output an http response header to send the user to a new location. Not surprisingly, this uses a Location: header, and works much like a html refresh meta-tag. It tells the browser to request another document at another location. Have the program redirect to your 409 personal page. (http://www.rit.edu/~yourid/409/).

Here’s an example of a Location header:

Location: http://www.w3.org/pub/WWW/People.html

How would you output this? You use a print statement to output this type of header, of course. The header is for the browser and tells it to look elsewhere for a document. Remember to output a blank line after the header! There is no html output by this program and that means, you do not return content from your program (so what header don’t you need?).

Test the Second Program: Create an index.html file for your cgi directory, and include a link to both cgi programs. When a user clicks on the link to the second.cgi program, s/he should be redirected immediately to your main 409 page.

Question to answer on your blog: Is this a useful thing? Why bother?

Dynamic Sites and CGI: FormMail Exercise

Now that you’ve done a little bit with CGI, I‘m going to have you retrieve a CGI script from an archive, and install it into your account on Grace. Then you’ll develop a form to access that script.

We’ll be using a script from Matt’s Script Archive called FormMail, which is used to email form inputs to you. Go to the archive and download the script now. You should also review at the ReadMe file for FormMail.

Part 1: Configuring and Installing FormMail

You’ll be installing the formmail script into the same directory where you placed the first.cgi script from the last exercise. The permissions should already be set properly on that directory.

Save/download and open FormMail.pl so that you can edit the necessary variables.

The first line of the file needs to show the location of perl on the server. On grace, the location is /usr/local/bin/perl (you can find this by doing the “which perl” command at the unix prompt).

Default: #!/usr/bin/per
Grace: #!/usr/local/bin/perl

After that, there are only three variables in the perl file that you will need to define:

1. The $mailprog variable must properly define the location to your server’s sendmail program. If this is incorrect, form results will not be mailed to you (because the program won’t know WHERE the mail program is on your system). It’s tricky to find the sendmail program on grace. You’d think it would be in something like usr/lib or even usr/bin. It’s in usr/sbin … and, if you type “which sendmail” at the prompt, you can verify this.

Default: $mailprog = ’/usr/lib/sendmail –i -t’;
Yours: $mailprog = ’/usr/sbin/sendmail –i -t’;

The next thing that must be changed is called @referers. This controls basic access to your formmail script. You wouldn’t want the entire world pointing to your server, right? Let them get their own script and install it themselves. (Think of how much a spammer would enjoy having free access to your mail scripts to blanket the world with more unwanted mail.) On mine, I changed this value to (‘rit.edu’,’lawley.net’) so that I can run the script from any of my RIT accounts or my server.

The default @referers looks like this:
@referers = (‘scriptarchive.com’,’209.196.21.3’);

Yours should look like this:
@referers = (‘rit.edu’);

Now only web pages on rit.edu folks can call this script.

The third one, @recipients, is the most important one… This one will stop spammers or hackers from using your form to pollute the world with unwanted e-mail! We can set this one to hold either domain names or specific e-mail addresses that the form can send mail to. (For an exhaustive description, see the Read Me).

It’s important to realize that you need to add the domain of each e-mail address you want to send to (sub-domains need to be listed separately!)

Default: @recipients = &fill_recipients(@referers);
Yours: @recipients = &fill_recipients(‘rit.edu’,’it.rit.edu’);

Now you can have the form send E-Mail to either your RIT address or your FirstClass address! While you could add something like ‘hotmail.com’, that makes the script less secure. The most secure approach would be to use specific addresses rather than domains.

Finally, because it’s a cgi script, you’ll need to change the name of the script from formmail.pl to formmail.cgi to get it to work. You can rename the file in any number of ways including using the mv command in UNIX or renaming the file before you install it. (Remember – since it is a script it MUST have execute permissions!)

Test the script by loading it directly in a browser; http://www.rit.edu/~yourid/pathtoyourcgidir/formmail.cgi. You should see a box with the name of the program and a copyright statement; if you get an error, be sure to check (a) permissions on the directory and the script (should be 755), (b) line breaks on the perl file, © correct perl address in the first line, etc.

Part 2: Creating a Form to Use FormMail

Now you need to create a form to call the script. The form should be somewhere in your www directory tree (but not in the cgi directory, ideally). Set the method=”POST” and action=”http://www.rit.edu/~yourid/pathtoyourcgidir/formmail.cgi”

One field on your form should be named “recipient” and should have a value of an email address with a domain that is included in the referrers array of the script (e.g @rit.edu or @it.rit.edu)

Use the documentation (the Read Me file on the FormMail page) to determine what other reserved field names are used by the script, and see if you can use them appropriately and successfully in your mail form.

Make sure you upload the HTML page with the form to Grace before you test it; otherwise the script will reject it because it’s not on an approved “referrer” site.

Open your form in a browser, fill it out, and submit it. Check your email. Did you get the information? If not, go back through these steps and keep trying until you get it installed correctly. (Sometimes there’s a delay in receiving the mail.)