DevRequestParamValidation - Project Zero

Project Zero	Download Documentation Community About
Development » DevRequestParamValidation Login\|Register\|Print

Validation of Request Parameters Design Discussion

Bug 5275

Validation scoping of work items

ZRM: Constrain the problem to ZRM based applications for initial proof of concept
Application Builder: Integrate with the Application Builder page editor used when creating forms
Dojo: Embrace the JSON schema for Dojo Data.
Validation : Server side validation of models data
Programmatic API : Server side filtering, validation and escaping of input data

Zero Resource Model (ZRM)

There are two pieces of work associated with the leveraging the ZRM schema/model design for request parameter validation.

Promotion of key functionality from ZRM into zero.core for validation of data against a model
Integrate more closely with JSON Schema for the definition of the ZRM model.
- JSON Schema has a pattern property which follows ECMA-262/Perl5 regular expression semantics.

Application Builder

Enhancements remain to to the Visual Page Editor for Data Binding between DataSource/Schema (ZRM) and Widgets on a page. DataBinding

Dojo

Work with community to determine if JSON Schema is the right choice for validating data for Dojo Data (we think the answer is yes)

Add functionality to be able to obtain the schema from the data store
Add the ability to call validate on the data for client side validation (either during Write or post-Write)

Dijits already have a fairly rich set of validation/filtering on the client. We need to fully understand its capabilities and how it dovetails with server side validation:

http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_validate.html

Note also that a JSON data structure can be easily extracted programmatically in JavaScript for a

element.

Dojo has a basic validation framework in the dojox in addition to dijit form elements: http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/validate/

In addition, there are a number of validation-related functions for strings inside that directory. These are the functions that could be used server-side as well if JS were available.

Validation

The goal of this piece of work is to have the behavior for validation for the client and the server to be identical so that users cannot distinguish between the client side and server side validation.

Align regex and other validation pattern function checks to handle possible cross language differences (for instance does javascript regex support the same patterns as java regex or php regex? -- if application has a custom filter or validator written in javascript, can we also use this same validator on the serverside using serverside javascript - Rhino)(Another option is to use IBM JavaScript on the server side--This is the JS implementation that Domino uses for XPages on the server-side, and doesn't have the legal issues that Rhino has).
There are many additional client-side validation functions that Dojo does today--written in JavaScript, for example credit card checks, ISBN, date values, etc. These functions could be called directly called if Rhino (or some other Server-side JS library is added), so that they would not need to be re-written in every server-side scripting language. ie. Just call the JS script directly.
Align status code and error messages for both the client and the server. Since javascript/dojo has it's own nls enablement of messages, we want to ensure that the server can also leverage these same properties files.

Programmatic API

For the most part, we would prefer convention to be used for handling the validation of input data. While this is the happy path, there should also be some level of programmatic APIs exposed for applications to leverage.

Validate API : Provide an API that can validate the input is of the correct type and within the constraints specified ( between the numbers 1 and 12)
Filtering API: Similar to the ACF APIs which allow active content to be removed, we should also provide an API to filter out input data. The example would be if you are expecting an int and you receive the value "abc123". The filtering API would remove the abc and return 123 back.
Escaping API: With the focus on web 2.0 applications (wikis and blogs) users may submit content that contain html tags. The purpose of this API would be a compliment to the filter and validate and can leverage the API already part of the core runtime XMLEncoder

Existing Functionality

There does in fact exist disconnected pieces that provided a starting point for an integrated story. Both ZRM and Dojo have validation frameworks.

ZRM

We should work to improve the ZRM pieces to be reusable. Although validation on model instances can be done without persisting the data, the 1.0 release will create persistence artifacts for ALL ZRM models. One goal of ZRM for the Silverstone release is to separate the persistence from other portions of ZRM, including using models for validation without persisting.

I should note that ZRM has two major pieces already in place....

A declarative format for data "shape"
A robust validation framework

Both the field "types" and validation framework are extensible. ZRM ships with the following field "types" and uses a JSON syntax modeled after the emerging JSON-Schema:

string
boolean
date
date-time
time
decimal
float
integer

"string" types can take on an optional "format". The shipped ones are:

large
email
phone
region

Some of these types have required and optional parameters. In addition to these parameters, all fields can be "required", constrained to a set of "options" values, and have a "default_value". Moving forward, users can provide a "validator_list" which runs through one or more validating methods, and can be "readonly".

With this declarative shape, data from an HTTP request can be "validated".

r6 - 24 Jun 2008 - 14:28:00 - chrism1

Syndicate this site RSS ATOM