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@sun.com> wrote:

>>>>> On Fri, 10 Apr 2009 15:21:42 -0400, Dan Allen <dan.j.allen@GMAIL.COM> 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.