The application is designed to be self-contained, i.e. that we don't rely on having Apache on the front. That's not to say that we can't or wouldn't put Apache into the mix but in general we've found that Tomcat can handle things using Filters and a properly thought out server.xml/catalina.properties configuration in a way that's just as secure, more efficient and easier to configure than the old Apache/Tomcat combo.
Claude Brisson <[EMAIL PROTECTED]> wrote on 08/22/2008 02:57:46 PM: > If you're using Apache in front of Tomcat, it's also very easy to forbid > some URLs to the outside world. In fact, along with its ability to > handle static files in an optimal way, Apache rewriting and security > scripting features are very good reasons to use it in front of the J2EE > container. > > Claude > > Le vendredi 22 août 2008 à 12:35 -0600, [EMAIL PROTECTED] a écrit : > > I've written a Filter - it needs more testing but it appears to be doing > > the job. > > > > Thanks, all. > > > > [EMAIL PROTECTED] wrote on 08/22/2008 11:39:30 AM: > > > > > 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] > > > > > > > > > --------------------------------------------------------------------- > > 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]
