Friday, July 14, 2006
EJAX parameter validation
A verb operating on a resource can take zero or more parameters. EJAX has three levels of parameter validation. The first level is entirely browser based and fires if JavaScript is active. The EJAX frameworks spits out a JSON description of the parameters. This looks like this:
This validation isn't always enough. For example password validation cannot be done in this manner. So there is a second level validation as well. This is a collaboration between the browser and the client, again, only if JavaScript is enabled. It takes the contents of all form controls using prototype.js' Form.serialize() and sends it to the action specified in the form. But with one twist: it adds the ejax:validate parameter. When this input is found by the EJAX generated resource classes they will only validate the control and just return a response code such as 200 OK or 400 Form invalid. The error response contains a detailed description of what control had the wrong input and what the user should do to fix it.
If JavaScript is disabled, or if the form is still submitted, or if some malicous program tries to send bad data to an EJAX resource the third level of validation comes into play. This is the final defense and takes place at the server. It simply validates the given user input against the specified parameter data types, before any other action will take place.
var my_form_parameters_text = {It's pretty equal to the parameter description for the resource. The EJAX.FORM.validate routine in ejax.js can take such a description and validate the controls, match the id in the parameters description against the contents of the controls. If an error occurs, the control is focused and an error message is displayed near it.
system_id:
{type: "positiveInteger"},
company_name:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
contact_name:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
email:
{type: "string", minLength: 1, maxLength: 256, whiteSpace: "collapse"},
password:
{type: "string", minLength: 1, maxLength: 32, whiteSpace: "collapse"},
password2:
{type: "string", maxLength: 32, whiteSpace: "collapse"},
address1:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
address2:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
city:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
state:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
zip:
{type: "string", maxLength: 16, whiteSpace: "collapse"},
country:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
...
This validation isn't always enough. For example password validation cannot be done in this manner. So there is a second level validation as well. This is a collaboration between the browser and the client, again, only if JavaScript is enabled. It takes the contents of all form controls using prototype.js' Form.serialize() and sends it to the action specified in the form. But with one twist: it adds the ejax:validate parameter. When this input is found by the EJAX generated resource classes they will only validate the control and just return a response code such as 200 OK or 400 Form invalid. The error response contains a detailed description of what control had the wrong input and what the user should do to fix it.
If JavaScript is disabled, or if the form is still submitted, or if some malicous program tries to send bad data to an EJAX resource the third level of validation comes into play. This is the final defense and takes place at the server. It simply validates the given user input against the specified parameter data types, before any other action will take place.
Comments:
<< Home
Nice design.
The third level is of course the "primary" validation. The others are just for the convenience of the user, to make for a smoother browsing experience.
Even without malicious programs, invalid data can still get sent to the server during testing, due to JavaScript incompatibilities, etc.
Post a Comment
The third level is of course the "primary" validation. The others are just for the convenience of the user, to make for a smoother browsing experience.
Even without malicious programs, invalid data can still get sent to the server during testing, due to JavaScript incompatibilities, etc.
<< Home