Web Design Best Practices
Web Application Authentication Tutorial:
Page 3 - Basic Login Form Explained
Well, that was neat. We presented a form, verified the user and password, and got our results. How did we do that?
Lets look a the basics. We used four web technologies to implement the login page. And nearly every page we develop will be using those same four technologies. If you already have a solid grasp of any of these technologies, feel free to skip ahead to information on using the Basic Login to Protect Pages.
- HTML, the basic page markup and underpinning of all web pages,
- JavaScript, a client side programming language,
- CSS (Cascading Style Sheets) for the presentation and design of the user interface, and
- ASP with VBScript, a server side programming language.
Let's look at the HTML first. (if you are familiar with the HTML tags for LABEL, LEGEND and FIELDSET skip to the next page)
All HTML pages start with three basic tags (each of which has a closing tag).
<html> <- The beginning of the markup
<head>
<- Client side code, META tags and the
page title go here
</head>
<body>
<- The page markup tags go here
</body>
</html>The markup for our form is really very simple.
<form method="POST" action="login.asp" onsubmit="return validate(this);">
<fieldset> <legend>Login Form</legend>
<div id="results"><%=resultMessage%></div>
<p><label for="userid">User ID:</label> <input id="userid" name="userid" type="text"> <span class="hint">test</span></p>
<p><label for="password">Password:</label> <input id="password" name="password" type="password"> <span class="hint">password</span></p>
<p><input type="submit" value="Submit" name="btnSubmit"></p>
</fieldset>
</form>
The <form> tag has many attributes, but you will use four of these the most. These are name, method, action and onsubmit.
The name tag (which we did not need in this example) is for a unique identifier for the form. I find that when using current W3C recommendations for client side programming, I very rarely use the name attribute but will use the ID attribute instead. (more about that later.)
The method attribute is usually GET or POST. With the get method, all of the form fields name and value pairs are sent to the form handler by the URL, for example:
nextpage.htm?field1=val1&field2=val2&field3=val3...
Since there is a limit on the amount of characters you can send on a URL, the POST method is most often used. In the POST method, the fieldname and value pairs are transmitted to the server (and next page) in the HTTP headers. Not only does this overcome the limit on the amount of data you can transmit on a URL, sensitive data, such as the password are not passed in public view. (That does not mean secure, just obscure.)
The action attribute tells the form what action to take, and is usually the name of a form handling page or script that will process the data submitted from the form. In our example, we are posting the form page to itself as it contains the script to handle the posted data.
The onsubmit attribute is an event attribute. When the form is submitted by the user, the onsubmit event will occur and will execute the action specified. The action specified in this page is a call to a client side (JavaScript) function that must return true or false. If it returns true, the form is submitted to the server as specified by the action attribute. If the function returns false, the form submission is stopped.
This allows us to perform form validation and any other preliminary steps needed before submitting the form. In our example, we perform basic form verification to verify that a value has been entered for both the user id and password fields before we allow the form to be submitted.
All the elements of the form are contained in a <fieldset> tag pair. The <fieldset> tag was introduced with the W3C recommendation for HTML version 4 in 1997. As you browse various web sites and code examples, you will see a lot of web forms implemented without the <fieldset> tags and will often find the forms using tables for layout and user interface.
This tag, and the related <LEGEND> tag makes your forms easier to use and maintain. It also makes your form page more accessible to screen reading browsers that are used by person's who are visually impaired. If you are designing a form for a business, this can give you a competitive advantage. This is just like having your site render in another language so you'll gain a wider audience to whom to offer your products.
Since it is 2005, it seems odd that web designers don't employ more modern HTML techniques. Some people learn one way of doing things and simply can't handle change. Or the development tools they use force bad design. In any event, you should use the <fieldset>/<legend> tags and CSS to layout the design of your form.
There is nothing particularly noteworthy about the input fields and the submit button. Of small note would be the divide that includes and ASP directive to write a status message to the form for the user's benefit.
<div id="results"><%=resultMessage%></div>
That simply communicates to the user of the form information useful to completing the form properly. While we hope to achieve a certain separation between our server side code and out HTML markup, the simple display of a status message is not inappropriate. To completely separate that from the HTML markup would require more work than it is worth.
Let's take a look at the client side form validation script.
