nath

• Sep 25th, 2006

 

Hi friend, i understood your problem.plz see the following sitesurely u can get the solution aBOUT VALIDATIONS.http://www-128.ibm.com/developerworks/websphere/library/techarticles/0311_fung_yu/fung_yu2.html#sec1-3BYE

K.HarikaReddy

• Sep 25th, 2006

 

Input validation refers to the practice of verifying that input from an untrusted source is acceptable and safe to use. This has a significant security impact because malformed data submitted by a malicious user is the direct cause of numerous exploits (including SQL injection and cross-site scripting) and generally causes an application to behave unexpectedly and outside of its security design.

The Struts Validator plug-in lets you cleanly encapsulate all of your validation logic in XML configuration files instead of Java code. The Validator plug-in assists developers by standardizing common types of validations, preventing validation logic duplication, and being easier to verify and change (no recompilation is required). Two things to consider when using the Validator plug-in:

1. There's a mechanism to validate the code of the ActionForm (org.apache.struts.action.ActionForm, the Java class in the controller responsible for handling user data). However, this doesn't offer the advantages described above and won't be discussed here.
2. Any business-level validation should be performed in the model, and the controller should be limited to semantic validation (correct length, type, acceptable character set). For instance, in the Validator plug-in you might ensure a credit card number is the right format, but you'd ensure it's a valid card in the business logic.

Here's how the Validator plug-in works:

1.  User input is encapsulated in one of the ValidatorForm classes (which extend ActionForm classes):

public class UserValidatorForm extends org.apache.struts.validator.ValidatorForm {
      public String firstName;
      public String lastName;
      public String phoneNumber;
      public String userId;
      ...
}

2.  Validation functions (several standard ones come pre-baked) are defined in validator-rules.xml. This rule calls a validation method from a custom class:

<validator name="userId"
classname="com.jdjexample.validator.UserIdValidator"
method="validateUserId"
      methodParams="java.lang.Object,
      org.apache.commons.validator.ValidatorAction,
      org.apache.commons.validator.Field,
      org.apache.struts.action.ActionErrors,
      javax.servlet.http.HttpServletRequest"
    msg="errors.userid">
...
</validator>

3.  Validation.xml maps which fields have to be validated by which rules:

<form-validation>
  <formset>
     <form name="userForm">
       <field property="firstName" depends="required">
        <arg0 key="firstName.displayName"/>
      </field>
       <field property="lastName" depends="required ">
         <arg0 key="lastName.displayName"/>
       </field>
<field property="phoneNumber" depends="required, mask">
<arg0 key="phoneNumber.mask"/>
<var>
     <var-name>mask</var-name>
     <var-value>
     ^D?(d{3})D?D?(d{3})D?(d{4})$
     </var-value>
</var>
</field>
</field>
     <field property="userId" depends="required, userId">
     <arg0 key="phoneNumber.mask"/>
     </field>
    </form>
   </formset>
</form-validation>