Date: 2005-01-10T13:09:19 Editor: DenisBalazuc Wiki: Apache Struts Wiki Page: StrutsCatalogHidingPagesUnderWEBINF URL: http://wiki.apache.org/struts/StrutsCatalogHidingPagesUnderWEBINF
no comment Change Log: ------------------------------------------------------------------------------ @@ -27,3 +27,19 @@ 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 [wiki:StrutsCatalogLinkOnlyToActions Link only to Actions] 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 [http://struts.apache.org/userGuide/dev_tiles.html Tiles] 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
