[StrutsCatalog]: *Hiding pages under WEB-INF* \[_Note: While this is a typical practice, it is *not* one most teams need to follow. In most cases,[Link only to Actions|StrutsCatalogLinkOnlyToActions] hides the page locations making this practice redundant._\] The container provides security for all files below WEB-INF. This applies to client requests, but not to forwards from the \{ { \{ [ActionServlet] \} } \}. (Though some versions of some containers may not support the forwarding behavior.) Placing all JSPs below WEB-INF ensures they are only accessed through Actions, and not directly by the client or each other. This practice enforces MVC at the Controller by ensuring pages are not accessed directly. However, if your pages need to access a number of other HTML resources, like images and stylesheets, it may be more convenient to leave them in the document root. As noted, if you are using[Link only to Actions|StrutsCatalogLinkOnlyToActions], then the address of your JSP's is never exposed anyway, and this practice loses much of its value. The Link only to Actions practice is usually sufficient. -- [TedHusted] ---- Comments: The real value of this pattern is to protect your application from improper usage. If, for some reason, someone knows the direct address of your JSP pages, s/he could use it to access your pages without going thru an action first. Hiding your pages under WEB-INF guarantees that this won't happen. -- [MarcusBrito] ---- I personally prefer to use filter for hiding pages. I set filter to return 404 on every request for \*.jsp page. I can also change filter to allow for example only index.jsp to pass, but all other pages to be unavailable. This is IMHO better than relying on container implementation. -- [IvanRekovic] ---- Another option for disallowing access to JSPs is simply to add a security-constraint for the role "nobody" for "\*.jsp". Unfortunately, it appears you have to add one "url-pattern" element for every subdirectory. I don't believe there's any way to specify something like "\*\*/\*.jsp", as in Ant. You can even disallow access to JSPs in the root of the app, like "index.jsp". You might think this makes it impossible to have a welcome page. However, one "trick" that I believe should work in all containers is to set your welcome file to "index.do", create a file called "index.do" in the root (contents are irrelevant), and create an action-mapping for "/index.do". This works because the servlet specification states that the named welcome file needs to exist, but then it hands the URL to the container to serve, which handles it just like any other URL. -- [DavidKarr] ---- Hiding JSP resources under WEB-INF is my privileged way of making sure pages do get accessed as intended. The major advantage compared to filters or security constraints configured in web.xml is that it doesn't rely on any configuration, which can be broken or buggy. It only relies on a feature brought by the JSP specifications itself that you are sure your container implements (if it implements the specification correctly). Security and user realm management can also become a difficult task in complex applications with various security domains and or pages. In the context of Struts, you can have a fine-grain control of what resources are accessible by using security role names in struts actions, added with module switching maybe. Moreover, as said previously by others, this enforces the [Link only to Actions|StrutsCatalogLinkOnlyToActions] paradigm AND removes the effort of writing security constraints with limited URL pattern matching, or writing filter classes. This is even more true when using [Tiles|http://struts.apache.org/userGuide/dev_tiles.html] where all the JSP pages are basically small lego pieces that form one single page. With a lot of well-separated JSP blocks (that need not care about the context they are run in), WEB.XML security configuration can become very tedious. The idea is "the less configuration I have, the less errors will appear". Having JSP files under the WEB-INF directory removes a layer of potential errors and configuration headaches. Also, in large projects, I find it much cleaner to have JSP pages grouped (I should say 'hidden') together within the WEB-INF, along with the JAR(s) and classes files they relate to in some way, and have the static content be separated and more visible to the production team who manages the static content. This separation can also prove much more convenient for maintainance and/or refactoring on a longer term. -- [DenisBalazuc] I've had some problems with this practice while porting an application from Websphere to an older version of Weblogic. It seems that Weblogic servlet container doesn't allow access to JSPs under the WEB-INF folder - even via forwards from Struts. -- [AndrewNewdigate]
  • No labels