tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Stang" <mst...@pingidentity.com>
Subject RE: DISCUSS: Page template: in context root or WEB-INF?
Date Fri, 05 Jan 2007 00:20:29 GMT
In general being able to access files just by specifying a URL to a server upsets people.
 I think they expect that it allows hackers to see into the system and maybe find a vulnerability.
 We have taken to putting in an index.html in any directory that might have files and be accessible.
 If Tapestry is the Controller then I don't think it is a good idea to shrug it off and let
the servlet "handle" things.  Having too many ways and means to access files upsets security
people.  And the number of holes in Tapestry already scare some people.



Mark J. Stang
Senior Engineer/Architect
office: +1 303.468.2900
mobile: +1 303.507.2833
Ping Identity

-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Thu 1/4/2007 5:15 PM
To: Tapestry development
Subject: DISCUSS: Page template: in context root or WEB-INF?
A recent check in allows page templates to be stored in the web application
root, much like they are in Tapestry 4.

To do this required a very ugly hack.  Tapestry 5 acts as a servlet filter
(not a servlet, as in Tapestry 4). Normally, requests for real resources are
simply passed through to the default handler.

I had to explicity check for  a ".html" extension, and pass that on through
to the rest of Tapestry's code path, because templates have a ".html"

This causes a couple of issues; for instance, eventually I want to have the
template extension be configurable (this is possible in T4) which makes
sense if some "pages" are really SVG or CSS or something else.

It also causes a problem for static HTML files; they are now treated as if
they were Tapestry pages, and an error ensues when the page class is not

Perhaps these could be addessed by adding more kludges.

I propose moving page templates to WEB-INF.  So they can be on the class
path, with the corresponding Java class, or in WEB-INF.

This causes an issue with WYSIWYG preview, because the path to static assets
will be somewhat off.  However, for any page that makes use of
onPassivate/onActivate (a mechanism where by additional information,
typically entity object primary keys, can be encoded as additional path
information), the page's base href will also be off.  In other words, paths
to static resources should be complete (leading slash and context name) to
be assured that they work correctly.

Anyway, how do people feel about this?

Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message