Howard, 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.
regards, Mark 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:[EMAIL PROTECTED] 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" extension. 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 found. 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
