Wednesday January 31, 2007
Mark A. Basler's Weblog
All
|
Java
Validation for Petstore 2.0's uploaded data through Ajax...
Recently I have been working on refactoring the error handling of the
just released Petstore 2.0 application. I
started by updating the validation mechanism for items that a Seller
could post for sale. The uploaded form is submitted using an Ajax
call in multi-part mime format. The Ajax file upload uses the
Dojo library to submit the form and I packaged all the functionality
into and easy to use JSF 1.2
component available through the Java EE 5 version of the Java Blueprints
Solutions Catalog
The validation of the form has multiple facets which are as follows:
- Are the required fields entered in the proper format before the
form is submitted (client-side validation)
- Is the Captchas value valid
- Is the size of the uploaded image too large
- Are the required fields entered in the proper format after the
form is submitted (server-side validation)
Client Side Validation
The first part was completed using typical web techniques by coding Javascript to check the form's data before it is submitted. If any of the required fields weren't entered or not in the proper format a message is shown to the user and the form submission is terminated. I chose to show all the errors on the page to the user at one time versus showing the user one error at a time. I think this is a far better technique, so the user can try and fix all the errors at once, instead of fixing one at a time and then resubmitting the form to see if there are any other errors. Part of this validation included checking to make sure the uploaded file has the proper suffix (.jpg, .gif or .png) and that the description field didn't contain a script or link tag for security. If Javascript files were permitted to be uploaded or display fields where allowed to have script elements in them then there is a potential security hole that hackers could use to hijack the page or misuse your resources. Below is an example of the client-side validation message that could be presented to a user:
Captchas Validation
The Captchas functionality was coded by Yutaka Yoshida. The Captchas validation was implemented utilizing a servlet filter. The CaptchaValidateFilter checks the uploaded Captchas value that is sent in a cookie (so the multi-part mime stream doesn't have to be touched) and validates it against a corresponding string that is set in the session when the Seller upload page is rendered. If the case insensitive values matches, then the upload proceeds. If not, then a status object is set with the error so it can be read by the client and shown to the user, then the upload is discontinued.
Upload Size Validation
For maintenance and security purposes, I put a limit on the upload size of approximately 100K. I didn't want the users to be able to upload monstrous images which could cause a maintenance problem in terms of disk space and put unnecessary load on the server, which could cause a form of denial of service attack. Since the upload is in multi-part mime format, allowances has to be made for accompanying data and multi-part mime overhead. I limited the overall upload to 150K which should provide ample room for a 100K image to be uploaded. If the upload size was less than 150K, then the upload proceeds. If not, then a status object is set with the error so it can be read by the client and shown to the user, then the upload is discontinued. I added this validation check to the servlet filter so processing would stop as early as possible, if the upload was too large.
Server Side Validation
On the server side the validation that was performed on the client is reimplemented. This functionality is necessary to catch cases where users disable Javascript on their browser or try to hack a submission by sending the request directly to the server using some alternate method. The risk of submissions being sent by the browser without Javascript turned on is mitigated by performing the actual submission of the form using Javascript, but utilizing other tools like plug ins, this preliminary defense can easily be overcome. With server-side validation you really must show all the errors for the upload at one time versus showing the user one error at a time. If you don't then the user must keep submitting the data and endure the propagation delay to see the next error. This functionality was implemented in each entity's specific class, for example, the Address class validates its own data, but since the Item class is a composite class, it validates is own data and calls the validation methods for any of the classes that it contains, like the Address class.
This is just an quick introduction to the validation techniques that were used in the Petstore 2.0 Seller file upload page. We will be writing a full blown article on the uploading of data that will cover these topics and more in greater depth and will also include coding samples.
To get notified of the release for any of Java Blueprints projects, you can check the RSS feed located on blueprints.dev.java.net.
Hope this helps ...
Thanks - Mark
Posted by basler Jan 31 2007, 12:02:02 PM PST Permalink Comments [1]

