cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: [proposal] Cleaning up our component library
Date Wed, 28 Jan 2004 15:28:23 GMT
Ralph Goers <Ralph.Goers@digitalinsight.com> writes:

> Our 
> environment has special security concerns that just won't 
> allow a scripting language - or even JSPs or XSPs for that 
> matter.  

Ok, I'll bite; why single out scripting languages and dynamically
produced pages?  What about dynamically compiled Java?  How about XSLts?


It is just as easy to inject a security hole into a non-scripted
language as a scripted one; perhaps easier since people rarely think to
inspect the byte streams of the compiled code where as the source of the
scripted language is all there is (assuming you trust the compilers and
interpreters).  

Banning scripting on the client side I might understand. This however,
seems like a very poorly thought out security policy; instead of
determining what the real security exposures are a blanket decision was
made to ban some very useful tools on the off chance they might be
misused.



Mime
View raw message