Actually I don't understand the security concerns, if you configure
correctly your web server you have no issue with the security of
template files inside the context ?!
What I liked about tapestry is the ability to have some sort of
WYSIWYG with the pages. If you force the html pages to be in WEB-INF
you loose many practical aspects. Designers will have to go in the
WEB-INF directory to change the html pages and they will be
confronted to all kind of files in there, that will make their work
harder. All static files such as images, css etc.. will have wrong
path and if you plan to use apache to serve static files such as
images and css you will get a big mess with relative or absolute URLs.
Concerning the fact that all html pages even static one are served
with tapestry, I don't see the problem with that. First: it might
even be a good thing that tapestry serves static pages as it will
cache them in memory and thus it will be even faster. Second: if you
have a lot of static pages you shouldn't put them in your context but
you have a separate folder served by apache called ("static") or
whatever where all static content goes, because if you don't do that
everyone will mess your tapestry pages because they want to update a
static page. I mean JSP don't leave in the WEB-INF, they are in the
context (it is the exact same problem) and it is not recommended to
put them in WEB-INF. If you want security you create a folder in the
context and you secure that particular folder.
Another solution for those two problems and I think it is the one I
should prefer is the following:
- All tapestry related pages should be in the context and have an
extension defaulting to ".tap" (as jsps have ".jsp")
This resolve the security problem as you can forbid access to
all .tap pages in web.xml or put all those pages in a base folder en
restrict access in web.xml !
This resolve the problem of static pages being served by tapestry
because they don't have the same extension!
One other thing I would like to mention: is that sometimes you have
static pages that point to another page of your application. In my
case for all the projects I worked on, nearly all static pages where
not static because i had to put all my links with @PageLink or
@ExternalLink to keep the sessionid and the correct servlet path.
Having a static page pointing to another static page or to a tapestry
page, it would be a nice having the sessionid encoded automagically
in the URL.
Well that was my two cents.
Numa
Le 5 janv. 07 à 01:36, Jeff Lubetkin a écrit :
Agreed. Our network security folks were adamant that anything that
looks like code must be under WEB-INF. Explaining that the servlet
protected this was not enough - the standards say "use WEB-INF to
prevent code visibility" so they insisted. This is what led me to
coding http://wiki.apache.org/tapestry/SpeclessPagesInWEB-INF.
I think WEB-INF is the best place for these files, and they should
either be there by default, or simple coding/configuration should
allow
them to reside there.
jeff
-----Original Message-----
From: Mark Stang [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 4:20 PM
To: Tapestry development; Tapestry development
Subject: RE: DISCUSS: Page template: in context root or WEB-INF?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
