Cincom VisualWorks Web Toolkit Tutorial : The Login Page Concept

The Login Page Concept

Now that we know how to access data files from within an SSP, it should be possible to create a page that allows an employee to login to the application. In order compare what the employee enters on the login page, we will need to know how to extract data from an HTML form.

This lesson describes an overview of the login process. Data will need to be passed from one page to another. There are various way by which this can be accomplished and this lesson discusses those options.

1. It is not necessary for VisualWorks to already be running for this lesson.

2. Our web architect has outlined the following pages for us:

Figure 1. The flow of pages

The file login.htm is an HTML form which allows the employee to enter their first name, last name and employee number.

The file validate.ssp will be used to collect the first name, last name and employee number from login.htm and validate those items against the employee file.

If there is a match, the employee should be directed to home.ssp. If there is not a match, then send the employee back to login.htm

The file home.ssp should simply welcome the employee to the TEACH system by displaying their name. It will also provide a link to a page that will display a list of courses for this employee only.

In order to fully understand this lesson, it is suggested that you proceed to the HTML forms primer in order to learn how to extract form data using the ASP (SSP) model.

Proceed to the HTML Forms primer.

3. We are faced with 2 issues:

How to return the employee back to login.htm from the validate.ssp page if the login was unsuccessful
How to inform home.ssp of who the employee was who signed on (or how to pass data from validate.ssp to home.ssp)

4. The first item is quite simple. To transfer control from one page to another, use the redirect: method of the response object.

response redirectTo: 'URL'

We will see this used shortly when it comes time to code the validate.ssp page.

5. The second item is not so simple. In fact, it is one of the most "non-web" characteristics of the web. In other words, the web is a "stateless" environment in that as you go from one web page to another, the browser does not keep track of anything except for the pages you have visited. So asking the web to remember who you are after you login to a particular page is asking quite a lot because the web was never really designed to do that.

Figure 2. How to pass data

To circumvent this "problem", the creators of the web servers (not browsers) had to create a way for their servers to remember who their visitors were. The solution boiled down to four options:

Forms
Query strings
Session objects
Cookies

In our case, we need to pass employee information from validate.ssp to home.ssp. Let's discuss what the best method is of doing that.

6. Forms - Forms require a page to be “submitted” (I.e. a user in a browser has to click on a submit button). We have already done that on the login.htm page but we need to get from validate.ssp to home.ssp. Using a form here doesn’t fit our scenario.

7. Query Strings - Query strings are parameters passed in the URL. They are "named pairs" delimited by a question mark and ampersands (&). They look like the following:

response redirectTo: 'home.ssp?employeeNumber=111111'

Query strings are limited to 2048 characters. This is usually never a problem since most web site use query strings for "key values" (I.e. one page passed a key value and the receiving page uses that value as a lookup). The usage of query strings depends a lot on on how much data needs to be sent to the next page. If you want just employee number, it's not a bad choice, but if you want all employee data, it may not be the best choice.

8. Cookies - Cookies are small files that a web server places on a user's machine that typically contain information about that user so that the web server can remember something about you at a later time. In other words, cookies are mechanisms that allow a web server to store its own information about you on your computer.

In the past, when the Internet was relatively new, people feared cookies, afraid that they were more than simple text files that might contain viruses or some other type of malicious code. For this reason, your browser has an option that you can set to disable cookies. However, the Internet public in general over the past few years have been educated on what cookies really are and have considered them quite harmless. In fact, you can view cookies that have been stored on your computer at any time (although their content may not make much sense to you).

As such, cookies would provide us a way to solve our problem. The validate.ssp file would create a cookie with employee information and the home.ssp page would read the cookie in order to extract the necessary cookie information.

9. Session variables - Session variables are memory-resident objects on the web server that can store data. Technically, session variables are cookies since cookies must be enabled on the client’s machine in order for them to work. However, session variables are more flexible and easier to use. Like cookies, session variables are useful when data needs to be shared among many pages, not just from 1 page to another page. Therefore, session variables would provide us another way to solve our problem.

What is the real difference between cookies and session variables?

The main difference between cookies and session variables centers around data persistence. For example, we need to ask the question "How long should our application remember who we are?". Should employees be asked to login everyday or should it be a once-only process?

Historically, the concept of cookies is for them to stay around forever (or until the user decided to manually delete them). A shopping site like Amazon.com always wants to remember (and thereby welcome) you whenever you return to the site. Session variables, on the other hand, have a timeout feature - 20 minutes by default - although this can be overridden. So, should Toyz Inc. employees be asked to login everyday or should it be a once-only process? The answer to that question might dictate which solution to use.

10. The development of our application will be an iterative process. The “final” solution will not be built the first time out; it will be a progression of improvements that we make to the original set of pages. To keep a history (or the progression of coding techniques), a simple numbering scheme will be used for each page.

Figure 3. The iteration of solutions

Our first solution will use cookies and all subsequent solutions will use session variables.

You should now have a good understanding of how to pass data from one SSP page to another.

You can pass data from one SSP page to another by using:

	Forms - data is typically entered by a user and sent via named pairs to the next page
	Cookies - small text files that contain useful information about a user that the web server hopes will stay around forever
	Query Strings - data passed via named pairs in the URL of a page
	Session Variables - memory-resident data that contains useful information about a user that the web server usually needs only for as long as the user stays on the site

You can redirect the user from one SSP page to another by using:

The redirect: method of the response object.