Wednesday January 31, 2007 
Mark A. Basler's Weblog
All
|
Java
Wednesday January 31, 2007
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]
Wednesday January 24, 2007
Adding Mashups like Digg to your page
Recently I added a mashup to Digg in the soon to be released Java
Blueprint Solutions Catalog viewer. It was as easy as
formulating a URL
with the appropriate query string that is dynamically populated as the
user clicks on the different articles/examples that the viewer
combines.
When the Digg image is clicked then the required information is sent to
digg.com in the query string of the
request. The Digg site then parses the request and continues
prompting the user. If the article exists, Digg will display it
and
prompt the user for comments (below), if it doesn't exist then the user
can
submit the article for others to Digg. For example this Article
URL will show something like the page below from Digg:
When creating mashups, there are different types of techniques to consider like, client-side mashups, server-side mashups and delegated mashups. Each have specific applications that they are suited for and are briefly described below:
Client-Side Mashup
A client-side mashup is where the integration/interaction with the mashup occurs in the client, like a browser. Google Maps is a great example of a client-side mashup. To utilize Google Maps you include Google's Javascript file in your web page and use the document API to create a wide variety of user interactive maps. Google also provides numerous examples to get your page prototyped quickly. The Blueprints Solutions Catalog wrapped the Google Maps functionality in an easy to use JSF 1.2 component that you can utilized by simply packaging the component jar with your application. This component jar is also used in the Petstore 2.0 reference application, so you can take a look at the component in action.
Server-Side Mashup
A server-side mashup has a server component that acts as a proxy to an exposed service. The server-side component(s) could add custom functionality to an exposed service, consolidate multiple exposed services or just pass through the result directly to the client for use. This type of mashup is used in the Petstore 2.0 reference application to retrieve the GeoCoding of an address for presentation on the Google Map and for retrieving an RSS feed for the news bar that is in the header of each page. The Blueprints Solutions Catalog wrapped the RSS bar into an easy to use JSF 1.2 component that you can utilized by simply packaging the component jar with your application.
Delegated Mashup
A delegated mashup is when information is forwarded to a site that then presents the result for the request. Like Digg, there are many other sites that use this form of interaction. PayPal is another example of a delegated mashup where a request is submitted to the PayPal site and then they continue prompting the user. Some sites like PayPal even provide a parameter for a call-back URL in the query string of the request. Once PayPal finishes the transaction, a request is sent to the call-back URL with optional custom fields populated. The Blueprints Solutions Catalog wrapped the PayPal functionality in an easy to use JSF 1.2 component that you can utilized by simply packaging the component jar with your application. This component jar is also used in the Petstore 2.0 reference application, so you can take a look at the component in action.
This is just an quick introduction to mashup techniques that were used in the Blueprints Solutions Catalog and the Petstore 2.0 reference applications. We will be writing a full blown article on this topic that will cover these subjects 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 24 2007, 02:35:44 PM PST Permalink
