I realized after sending that the /resources path is used for serving publicly accessible resources such as JavaScript libraries and CSS files. Obviously, that is fine...so consider my concern in regards to composite components only and their placement. To extend my point, there is a distinct difference between public resources and protected ones. Composite components are protected resources. So even using the same folder name, one at the web root (public resources) and one inside WEB-INF (composite components and artifacts) is a reasonable, yet consistent, suggestion. -Dan On Sun, Apr 26, 2009 at 2:02 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > I've been putting together a JSF 2 example for Seam/Web Beans as a way to > feel out some of the new features in JSF 2 and I came across another > hangup > regarding the path of the composite components. The default (and fixed) > path > is /resources inside of the web root. The problem here is that this folder > is not protected in any way by JSF. So assuming I have the following > composite comonent tag: > > /resources/property/display.xhtml > > I can access this out of the box using this servlet path > > /resources/property/display.jsf > > So developers will unknowningly be adding new public pages to their > application (although certainly broken in part) by creating composite > components. > > There are two ways I would approach this from the spec to lock things down > by default. Please respond if you have any feelings about these choices. > > #1. Don't allow view IDs to be referenced directly under the /resources/* > path. > #2. Make the default resources path /WEB-INF/resources > > I strongly perfer option #2. I really don't like the fact that JSF is > consuming a top level folder in my web root for it's own use. It is not > clear as a developer coming into the project how it differs from other > folders. Plus, it blocks my use of the resources path in my URL. Anything > under WEB-INF is invisible and thus a perfect candidate for extension > folders. > > As a side note, it would be nice if JSF could also provide a filter to > protect direct access to view IDs (*.xhtml) out of the box, or perhaps a > switch at the very least in the RI. Malicious spiders can so easily locate > insecure JSF applications simply by trying URLs with *.xhtml instead of > *.jsf. > > -Dan > > p.s. I realize that the suggestion Ed made below is a workaround for my > concern, but it seems like a pretty inconvenient way to keep an > application > secure (when security should be convenient to implement). > > On Mon, Apr 13, 2009 at 3:01 PM, Ed Burns <Ed.Burns(a)sun.com&gt; wrote: > >> >>>>> On Fri, 10 Apr 2009 15:21:42 -0400, Dan Allen < >> dan.j.allen(a)GMAIL.COM&gt; said: >> >> DA> Another question came up at the JSF 2.0 presentation last night, this >> one >> DA> about composite components. >> >> DA> Can composite component namespaces/directories have multiple nested >> DA> directories? Same question with resource locations? >> DA> http://java.sun.com/jsf/composite/storefront/form/ >> >> The way we agreed to do this was the following syntax in a >> facelet-taglibraryA.xml file: >> >> <facelet-taglib> >> <namespace>http://domain.com/path</namespace> >> <composite-library-name>compositeTest</composite-library-name> >> </facelet-taglib> >> >> And this in a facelet-taglibraryB.xml file >> >> <facelet-taglib> >> <namespace>http://domain.com/path/nested</namespace> >> <composite-library-name>compositeTestNested</composite-library-name> >> </facelet-taglib> >> >> Yes, you are correct that the resource naming scheme prevents nested >> resource libraries. Nested resource libraries were not on the list of >> requirements when we designed this feature back in November of 2007. We >> will not accept this requirement change at this point. >> >> Ed >> > > > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://in.relation.to/Bloggers/Dan > > NOTE: While I make a strong effort to keep up with my email on a daily > basis, personal or other work matters can sometimes keep me away > from my email. If you contact me, but don't hear back for more than a > week, > it is very likely that I am excessively backlogged or the message was > caught in the spam filters. Please don't hesitate to resend a message if > you feel that it did not reach my attention. > -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.