Changing Prices in a Web-based E-Commerce System
An HTML form allows a website user to provide input to a website via the ubiquitous text field, list box, radio list, check box and other elements. Many e-commerce systems require the user to fill out multiple forms, one after another, to complete a purchase. Why is this done? Typically for usability and page load time concerns. Placing all of the input fields on one page makes the form daunting. Additionally, the HTML code for that single form is then quite large, resulting in long page load times for those impatient Web users.
Since HTTP connections are stateless, something must be done to maintain state among the multiple forms. Cookies are one option. Another option is hidden form fields - hidden text fields that contain state-related data. These hidden text fields are NOT displayed in the browser's GUI, but the information they contain is sent to the Web server when the form is submitted. (The HTTP POST method is what accomplishes this.)
Let's consider a real-world example to clarify the hidden form field concept. A Web-based system Testware tested sold individual songs that you could purchase for a small fee and download to your PC. (The exact nature of the system was somewhat different, but we need to disguise it for client confidentiality purposes.) A sequence of three forms was completed to make a purchase. The first form contained a Java search applet that allowed you to browse the available songs by category - jazz, rock, classical, etc. Upon finding the song you wanted, you would select it and click the Purchase button to proceed to the second form. The second form displayed the details of the song you chose and required you to enter your credit card and contact information. The third and final form allowed you to review your selection and the credit card/contact information for correctness before committing to the purchase.
While testing the system, we selected the song "In The Mood" on the first form and proceeded to the second form. Our browser's cookie option was set to "prompt," but we were never prompted to accept or reject cookies while testing. Since this signaled the site wasn't using cookies (and we confirmed this fact with development), we guessed that hidden form fields were being used to "remember" the song we had selected. To test this hypothesis, we brought up the HTML source code for the second form using the View Source in my browser. We were testing with Microsoft Internet Explorer, so the code came up in the Windows Notepad. We used the Find function in Notepad to search for the word 'hidden' and found the following block of code.
<input type="hidden" name="selectedSong"
value="In The Mood">
<input type="hidden" name="sessionID"
value="2265VX">
<input type="hidden" name="itemCode"
value="850574">
<input type="hidden" name="itemCost"
value="2.99">
The first hidden form field named selectedSong is keeping track of the song selection we made on the previous form. The second hidden field, sessionID, is a unique ID corresponding to our shopping session on the site. The third hidden field, itemCode, appears to be the numeric code of the "In The Mood" tune. The fourth hidden field, itemCost, appears to be the purchase price of this song.
Hmmm. It's OK to send the cost to the browser as HTML text, to display the item price to the user. However, that's not what is happening here. Since the price is being sent in a hidden form field as part of the second form, that price will be sent back to the server when I submit the form. So, what happens if we edit this hidden price field? Will the site actually use the altered price (hopefully not), or will it look up the price of the song in the server-side database and ignore the altered price (hopefully)?
To find out, we saved the second form to a local hard drive using IE's File | Save As function, loaded this page into Notepad, changed the price from $2.99 to $0.01, loaded the edited page back into the browser and attempted to complete the purchase. Lo and behold, the server used the edited price and we were able to purchase the song at a significant discount. The next thing to try would be making the price negative, perhaps -$10, and seeing if we would actually get a $10 refund on the credit card being used for testing. Other tests included changing the other hidden form fields and changing combinations of hidden form fields. Interesting things often happen!
We made several "reduced" purchases in this fashion and then had the site developers check the backend database and credit card charge log. They confirmed that the purchases with edited prices were going through without any problem. To resolve this issue, development reworked the form code to completely avoid sending pricing information in hidden fields. Instead, all pricing information was read directly from the server-side database that was unavailable to the general public.