1:02 a.m.
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> wrote:
>>>>> On Fri, 10 Apr 2009 15:21:42 -0400, Dan Allen
<dan.j.allen(a)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.