Cincom VisualWorks Web Toolkit Tutorial : The J2EE Logon Page Concept

The J2EE Logon 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 logon.htm is an HTML form which allows the employee to enter their first name, last name and employee number.

There will be a servlet 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 main.ssp. If there is not a match, then send the employee back to logon.htm

The file main.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 JavaBeans primer and the HTML forms primer for in order to learn how to extract form data and access objects using the J2EE model.

Proceed to the JavaBeans Primer for J2EE

Proceed to the HTML Forms Primer for J2EE

3. We are faced with 2 issues:

How to return the employee back to logon.htm from our servlet if the login was unsuccessful
How to inform main.ssp of who the employee was who signed on (or how to pass data from the servlet to main.ssp)

4. The first item is quite simple. To transfer control from one page to another, use the redirect: method by subclassing VisualWave.HttpServlet.

self redirectTo: 'URL'

We will see this used shortly when it comes time to code our servlet.

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 our servlet to main.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 logon.htm page but we need to get from our servlet to main.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:

self 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 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 servlet would create a cookie with employee information and the main.ssp page would read the cookie in order to extract the necessary cookie information.

While this looks good "on paper" or "in theory" (and it works in the ASP model), it will not work in the J2EE model. If you send a cookie with a redirect in the same response, many browsers will either ignore the cookie or store it for future requests, but not pass it back in the redirect request. Just in case you don't believe this, our first phase of the logon process will attempt it. You will see that it does not work. Even though it will not work, do not think this phase was a waste of time. The work done here will be a step toward our final version since where we replace cookies with sessions.

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. We will also change the names slightly so that there will not be any conflicts with any of the ASP model pages.

Figure 3. The iteration of solutions

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

You should now have a good understanding of how to pass data from a servlet to an SSP.

You can pass data from a servlet to an SSP page 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 the servlet to another by using:

The redirect: method of self since our servlet will be a subclasss of the VisualWave.HttpServlet class.