struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d..@struts.apache.org
Subject [Apache Struts Wiki] Updated: StrutsCatalogHidingPagesUnderWEBINF
Date Mon, 10 Jan 2005 21:09:19 GMT
   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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message