On 05.Nov.2002 -- 11:52 AM, Torsten Curdt wrote:
> > As the document points out, input validation is crucial. Cocoon offers
> > input validation through XMLForms and the *ValidatorActions,
> > e.g. the FormValidatorAction.
>
> As you say - it's crucicial. I think we should force this in any way.
I can't think of a one-size-fits-all solution. There are areas where
input validation is impossible and unnessary, too.
[snip]
> You are true most ESQL pages are save due to the use of prepared statements.
> But I doubt people use in only it that way. This should at least stated in the
> docs explicitly. I know we cannot make it save against every abuse - but we
> can make it harder for every unaware user.
Sure. The docs most likely neither reflect this aspect nor mention
PreparedStatements at all. Must check.
> But we encounter this problem (not only SQL related) everywhere. That's now
> even worse since be provide an easier way to incorporate external variables
> into the sitemap. That's exactly where the Filter proposal was aiming at!
I agree with you in that validation should be done. As for the filter
proposal, it is not necessary IMO because you could just implement
such a filter as input module and stack that on top of others. I've
recently cleaned up the "meta" module stuff, making it more apparant
what goes on and how to write additional "meta" modules.
Fictious example:
<component-instance name="my-app-request-param" src="org....MyFilterModule">
<filter-rule ......>
<input name="request-param"/>
</component-instance>
> We could even filter at Request level! But that's kind of problematic since we
> the Request has almost a per page page context of what is allowed and what is
> not.
>
> page1.html - request accepts attribute "sid" being a number
> page2.html - request accepts attribute "aid" being a regexpr [...] (but not
> sid)
> ...
> and even combinations!
One could apply the usage pattern other already use: every pipeline
starts with the request generator and everything else is done through
transformations.
> So I that's why I though the InputModules are now the preferred way to include
> such facility. If every external variable would come from an input module we
> could easily force security with them.
>
> Of course the closer to request the saver it is... since then there is no way
> around it. But this would need incompatible changes - which most likely a
> blocker.
What change do you have in mind?
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
