Advanced form validation-submitting a form for multiple times

Form Validation | advanced | Submit a form the challenge for each developer is to predict what the user can or will do-which is more difficult for web developers because his predictions must take into account the diversity of the web and the lack of a true session control mechanism. If you have created an ASP application that uses forms, you may have encountered some strange problems, such as data transfer two times, incomplete reception data, or user report forms that are not displayed correctly. Even though you've inserted all the client-side and server-side scripts required to validate the data, there are still a lot of exceptions to the form. These exceptions are related to unexpected user behavior or misuse of browser bookmarks. This article focuses on some of the typical situations that can easily cause a form problem: Users accidentally send data repeatedly, using an intermediate form directly in a multi-step form.

Data replication

It is a common situation to send data repeatedly through a form, but it can cause problems. Ideally, a user would come across a form on a Web site, populate it with the correct data type, submit it to the server that processed the data, and then send the user a confirmation page as a response, and then the user could do something else. What happens if a user visits the front page again, uses the Back button, and then accidentally sends the data again? If you do not anticipate this scenario and are prepared, the data will be transferred back to the server and processed again. Imagine that this data is an order or a hotel reservation, which will bring unpleasant results.

Terminating duplicate data transfer

To avoid data that is repeatedly sent to the server incorrectly, you can check the server side to make sure that users are aware that they are sending data. The example used here contains a simple form with a single text box, the form receives some text, and then sends it to an ASP page that displays them. To ensure that users do not send the same information two times, you need to indicate that the data has been received by the server. The best place to store this information is a session variable. Defines a session variable session ("submitted") that is initialized to False when the user first arrives at the form, setting it to true when the user makes the initial data transfer. If the user is accessing the form during the current session, there will be a related duplicate submission.
So users can only repeatedly send data to the server on purpose. Now look at the code that performs this checksum. An ASP page that establishes the form and verifies the sent data (form.asp at the download) has the following structure:
〈html〉
〈head〉
〈/head〉
〈body〉
〈% If session ("submitted") Then%〉
!--Code showing the warning message--〉
... 〈% Else%〉
!--Code showing the form--〉
... 〈% end If%〉
〈/body〉
〈/html〉

Both the form and the warning messages are created from the same ASP page. The form includes standard HTML code, referencing the Manageform.asp page as its action attribute:

〈form method= "POST" action= "manageform.asp"
Send me some data:
〈input type= "text" name= "Data"
〈p〉
〈input type= "Submit" value= "Submit"
〈input type= "reset" value= "Cancel"
〈/form〉

The manageform.asp page receives the text sent by the user, displays it, and sets the session variable submitted to true:
〈html〉
〈head〉
〈/head〉
〈body〉
You have sent the following information:
〈p〉
〈%= Request ("Data")%〉
〈% session ("submitted") = True%〉
〈/body〉
〈/html〉

So when the user returns to the form, test the session variable submitted, and when its value is true, the user is sent a warning message instead of the input form. This warning message is written using a combination of HTML and client side JavaScript code:
〈script〉
function Sendanswer (answer) {document. AnswerForm.answer.value = Answer document. Answerform.submit ()}
〈/script〉
You are have already submitted some information to this WEB site.
〈br〉do you want submit again?
〈p〉
〈form name= "Answerform" method= "post" action= "checkanswer.asp"
〈input type= "button" value= "Yes"
〈input type= "button" value= "No"
〈input type= "hidden" name= "Answer" ""
〈/form〉

The form contains two buttons (Yes and No) and an implied control field (answer) in which to save the user's selected value: Y or N. This value is set by the JavaScript function Sendanswer (), which also sends it to the Checkanswer.asp page to perform the correct redirection. If the user chooses the No button, checkanswer.asp verifies the implied control value and redirects it to a normal welcome page, and instead sets the session variable submitted to false and redirects it to the form page again.
〈% If Request ("answer") = "Y" Then session ("submitted") = False Response.Redirect "form.asp" Else Response.Redirect "WELC" Ome.htm "End If%〉

controlling browser buffers

If you have implemented the above method, you will find that this method works only if you type the URL in the browser's address text box to return to the form. It relies on the buffer mechanism of the browser. If you use the Back button to return the page, the browser detects its buffer to find a copy of the page. It will use the cached page instead of making a request to the server. So the server cannot verify on the session variable submitted. To avoid this situation, you should suppress the browser's page buffers. This is done by processing the response object in the form page. There are several ways to cancel a page buffer. All of these methods depend on the address indicated in the HTTP header file to the browser. But all browsers respond differently to the instructions sent by the server, so it's best to send more instructions to suppress the buffers for more browsers, as shown in the following code:

〈% Response.AddHeader "Cache-control", "private" Response.AddHeader "Pragma", "no-cache" Response.ExpiresAbsolute = # January 1, 1990 00:00:01# response.expires=0%〉

The first two lines of the above code use the AddHeader method of the response object to attach the header information to the HTTP header file. The Expires and ExpiresAbsolute properties mark the current page with the duration information of the page in the browser buffer. In a form page, these lines must be inserted before all code, because the information they refer to is placed in an HTTP header file and sent to the browser before all output.

Multi-Step form

If a form requires a lot of data, it's a good idea to divide the data you require into smaller forms, so that users can populate the form step-by-step, rather than waiting for the form to load many HTML controls. There are also situations where some of the controls in the form are not entirely necessary and can be filled line by row with the data that has already been submitted. Use a multi-step form to allow you to display custom forms that rely on the user's previous answers. A problem occurs if the user sets an intermediate form as a bookmark in the browser. In a subsequent session, the user tries to get to the form and submits the data, which is already outside the context because the session data that should have been collected in the previous form is lost.

Avoid using intermediate step forms

To avoid these problems, you can store the status of the current data collection. This state can be represented by a session variable to record whether a particular step has been performed---whether the user has populated the given form. In a multi-step form, each form can be implemented by a Boolean session variable. If the form is not processed, the variable is false, and the opposite is true. The second example in the Download section shows a two-step form: The first form requires a user name, and the second form displays a combo box whose list items depend on the user name provided by the first form. The first form is associated with a session variable requested1, and you can imagine that the second form is associated with the variable REQUESTED2. The session variable requested1 is set to True when the user requests the first form (form1.asp):

〈form method= "POST" action= "form2.asp"
Your name:〈input type= "text" name= "name"
〈p〉
〈input type= "Submit" value= "Submit"
〈input type= "reset" value= "Cancel"
〈/form〉
〈% session ("requested1") = True%〉

This value will be validated by the next form (form2.asp) to determine whether the requirement is met. In fact, the REQUESTED1 variable is validated when the user requests a second form. If true, the second form is sent to the browser and the REQUESTED2 variable is set to True. If False means that the user wants to use the second form directly, the browser redirects to the first form. The following code is an ASP page for the second form:

〈% If session ("Requested1") Then%〉
〈html〉
〈head〉
〈/head〉
〈body〉
!--Code for the second form--〉
... 〈% session ("requested2") = True Else Response.Redirect ' form1.asp ' End If%〉
〈/body〉
〈/html〉

It is important to note that the checksum for requested1 must be performed before the 〈html〉 record, allowing for possible redirection. In fact, redirection is an indication to the browser that it appears in the HTTP header file before all the HTML code.

Conclusion

The two techniques demonstrated in this article allow ASP developers to control some strange situations that can cause users to repeatedly send data through a Web table one-way server. Each technique solves a specific problem, so it's a good idea to mix the two and manage two session variables in each form of the ASP application.