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 15:44:07 GMT
>> 4. Some users don't want additional protection. They are happy with the
>> current level of (lack of) protection, and add their own as needed.
>> Hunsberger)
> AFAIU some would also like to have a centralized management...

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 Cocoon. 

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