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

[Dan Allen]

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

> >>>>> On Fri, 10 Apr 2009 15:21:42 -0400, Dan Allen <dan.j.allen at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090426/a8dc2b3f/attachment.html