cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Lewis" <>
Subject RE: SQL Injections: Wrapup
Date Wed, 06 Nov 2002 16:27:58 GMT

With the caveat that I read the list, but have not worked with many of the features I read
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
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
thier own of course, and if I understnad correctly, would even allow fairly complex cases
like the
credit card type and number check.

>>> 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.
> (Peter
>>> 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
> 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
> cases of this, things like where if a user picks a credit card type then the credit card
> 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
> 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
> 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
> implies that all request parameters get converted to a DOM tree or SAX events.  For me,
> 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
> 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
> idea...) I'd really like to see some discussion on this idea, am I just missing something
> completely?
> --------------------------------------------------------------------- To unsubscribe,
> For additional commands, email:

"The heights of genius are only measurable by the depths of stupidity."

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

View raw message