Deploying our lessons on the Web can involve a number of security issues - validating the student's login entry, verifying the student's identity, and checking to see if the student attempts to retry a formal exam that he or she has completed.
In this chapter, we will discuss
Usually, the validation begins in a login page, where the student must provide his or her ID and name. The validation checks to see if the student has typed in all the necessary information in the form provided. It also checks if the information entered is in the correct format.
In Chapter 4: Previewing Web Lessons Locally, we explained that Digital Teacher web application comes with two login file examples - one for the HTM type lesson and another for the ASP type. These login files are included in the Digital Teacher Web Application only because we need to
1. provide you with a starting point to access the Digital Teacher lesson pages
2. show you which form elements are required in the login page
Therefore, you can (will probably) modify these login pages to your own design. To design your own page, you need to have a basic understanding about HTML, and also perferably about Javascript. If you don't, just refer to the scripts in the example files and modify them.
For demonstration purposes, the dtLoginNT.htm file example contains forms for both students and teachers. You would probably want to divide them into two different pages. The teacher's login form is to provide teachers in your organization with access to the Digital Teacher online grade book. We will discuss this further in Chapter 7: Viewing Online Gradebook.
When the student browser loads the .ASP type lesson, the student login data is sent to our server so that we can respond back to the client depending on the data received. On the other hand, because there is no server-side processing for the Digital Teacher's HTM type lessons, there is no way to find and remember what the student said in the login (or the lesson) page. Still, using the cookie, we can at least secure our lesson by creating a password-protected lesson page to prevent from unauthorized people accessing the lesson.
The cookie is basically a small storage unit that we can create on the client's (in our case, the student's) computer. When the student types in his/her ID and name on our login page, we secretely create a cookie to store that information. Later, we retrieve the cookie data when it is needed, usually within inside our lesson.
We can create the cookie temporarily or semi-permanently. For example, if we would just want to use the cookie data during his or her stay in our lesson page, we would want to create a cookie in the student's computer memory, which will disappear when the student closes the browser. On the other hand, if we want the cookie to remember the data longer so that we can grab the cookie data when the student comes back to our page later - say, next day, we will want to create the cookie in a file on his or her computer disk.
Note 1: Using the cookie is only useful within the scope of the browser. With the cookie alone, we can neither verify the student's identity nor retrieve his or her performance results from the Digital Teacher's HTM type lesson. To include these functionalities in your HTM type lesson, you need to implement another mechanism, perhaps using the CGI scripts and the server-side data files.
Note 2: Using cookies are not necessarily a bullet-proof method for sending and retrieving data from the client computer. They can be rejected anytime. For more information, please read a Javascript book.
When we generate a Digital Teacher HTML type lesson, we can decide on whether the lesson should use a cookie or not.
By checking the [Use cookie] check box, we instruct Digital Teacher to include a cookie-related Javascript script in the HTM type lesson file we generate. When deployed, the login page creates a temporary cookie, and the lesson page retrieves the cookie data, perhaps to check
- the student's ID or password
- time-out lesson
Validation and cookies don't do any good in checking a student's identity. Verification does.
In order to verify a student's identity, a database (See Files generated for each type of lesson) that contains the information about the student must already be available on our server. When the student logs into our lesson, we check his or her identity by comparing the login data to the data stored in our database.
In this way, we verify the student's identify, check to see if the student has the right
to access our lesson, or monitor to see if he/she is attempting to access a lesson,
which he/she has already completed.
Copyright 2001-2002 Francis Software, Sunnyvale, California