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: XSL Security question
Date Thu, 30 Jan 2003 17:37:02 GMT
> What is a "skin" to you? Some sites need dramatically different XSLT to
produce 
> their final result.

A "skin" to me is the ability to swap look and feel within a single
application.  Knowing a bit about what you guys do it seems to me that
you've got a different kind of problem (not sure what you'd call it), but I
can see how you might consider it similar to skins.

> Site 1 needs to use an HTML 4.01 table based layout with pixel precision
to sew
> together images to produce a flashy kind of site.
>
> Site 2 wants to use XHTML 1.0 CSS layout and does not require pixel
precision.
>
> The skinning of the site is done in two completely different layouts (and
output 
> types).
>
> How would you do this without different skins?

I think you mean "without different XSLT"?  If you really wanted to jump
through hoops I could see how one could dynamically create the XSLT from XML
based site specifications that you created.  However, in this case it might
be just as pragmatic to use different XSLT, but I'd be very careful on who I
let create the XSLT...

<snip>

> That being said, we have been very selective as to who we take on as a
client (we
> are a pretty small company). I have turned away potential clients that I
found
> suspicious. And we have been doing most the XSL(T)...

There you go... :-)

>> Other than that, if Saxon (or the underlying Java engine) has any 
>> potential buffer overflow problems, or other Sandbox leaks then you've 
>> given people a nice Worm building environment (since XSLT is Turing 
>> complete)...
> 
> Wouldn't this be a problem with anything?

Well only if you give people a way to exploit it: using XSLT as a script
engine potentially lets any script writer have a go at cracking open the
bugs.  If the XSLT engine is only running XSLT that you control then only
you get to expose the bugs...

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message