I don't think that'll help: 1 - the mappings in web.xml are such that *.vtl URLs will be directed to the VelocityViewServlet; 2 - the templates are actually in a JAR in WEB-INF/lib/ - they're not available as static content via the default servlet.
With this setup, any *.vtl URLs will be handled by the View Servlet, which will process the requests by merging with whichever template is requested. Charles Harvey III <[EMAIL PROTECTED]> wrote on 08/22/2008 11:23:57 AM: > Put your templates in /WEB-INF/templates. Than nobody can access them > and there is no need for a filter. > > > Charlie > > > [EMAIL PROTECTED] said the following on 8/22/2008 12:17 PM: > > My web app uses the Velocity View Servlet with a mapping "*.vtl" (I use > > .vtl in preference to .vm for my templates; .vm I reserve for VelociMacro > > files). Users should be accessing the system with URLs with the pattern > > "*.do", which maps to Struts. The Struts ActionForwards then reference > > *.vtl URIs for the presentation step. All fairly straightforward, I think. > > > > The problem is, what's to stop a user typing in the name of one of my .vtl > > templates directly into their browser address bar? (or maybe worse, > > generating a POST request that contains all the context data so that it > > appears to render correctly)? > > > > There must be a way to secure this. A Filter or Valve, maybe? (The webapp > > will be deployed on Tomcat 5.0, 5.5 and possibly 6). What do people here > > do? > > > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
