cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: SQL Injections: Wrapup
Date Wed, 06 Nov 2002 19:12:34 GMT
> With the caveat that I read the list, but have not worked with many of the
features I read about,
> wouldn't it be posible to create a set of Input Modules to do validation?
I recall a discussion
> about having input modules be able to wrap other input modules, so you
should simply be able to
> access values through a set of validation modules. This would avoid having
to push the parameters
> to SAX or DOM, would be completely optional, and should be extensible,
allowing peopel to add
> thier own of course, and if I understnad correctly, would even allow
fairly complex cases like the
> credit card type and number check.

Well, yes that's one approach, but let me make another requirement explicit:
I don't want to have to write Java code every time a validation rule is
added!  In our case validation rules change a lot.  If the inputModule
approach can be made to work with XML schema and other rules then that would
work fine.  

That in fact is sort of how we're currently approaching the issue, but in
our case we have a general action handler.  It fires up a entire Xalan
transformation behind the scenes to run an XSLT rule spec against the
RequestGenerator input (aggregated with other data).  By wrapping a
transform in an action we can get the success/failure behaviors pretty easy,
pick up schema validation and use XSLT based validation rules.  Our approach
is currently extremely specific to our application.  With a lot of work it
could probably be made more general.  However, it doesn't completely match
up with the Cocoon architecture, thus my interest in seeing if there is a
better way to design all of this...

>> What I'd really like to see is a good general infrastructure within
Cocoon for doing validation
>> in general.  Part of my message (probably lost in the volume of my
comments) was that for some
>> of us the problem is bigger than validating individual parameters on a
one-by-one basis and we
>> need the capabilities to look at combinations of things.  Many developers
probably have simple
>> cases of this, things like where if a user picks a credit card type then
the credit card number
>> should match up with that type (each type of card has certain valid
ranges of numbers).
>> As such, I don't see that adding parameter level convenience methods
really has that much value
>> when compared to the problem as a whole (although it has some appeal).
I'd rather see the
>> development effort go into providing a general validation framework for
>> I've also asked if it isn't appropriate that we adopt the already
existing methods for
>> validating XML; in particular, validation against a DTD or schema.  The
biggest objection to
>> this is that, to date, there are pretty big performance issues associated
with such validation.
>> Architecturally it also has an interesting implication for Cocoon in that
it more or less
>> implies that all request parameters get converted to a DOM tree or SAX
events.  For me, that's
>> not a big deal (since we do it anyway), but for the existing Cocoon
architecture its a definite
>> change. None-the-less I think this is likely the way we should go for the
long run...  One can
>> cache compiled schema and we may even want to go as far as supporting
only some minimal subset
>> of an existing schema language just to keep things a little quicker.
Also I'd like to see a
>> stronger emphasis on DOM or SAX
>> representations for all Cocoon parameters in the long run. (IE; do we go
as far as having
>> Cocoon view all data as DOM trees/SAX events instead of Maps? That sounds
like a Cocoon 3
>> idea...) I'd really like to see some discussion on this idea, am I just
missing something
>> completely?

To unsubscribe, e-mail:
For additional commands, email:

View raw message