Re: [jsr-314-open] another important composite component template concern

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.