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:<br>
<br>/resources/property/display.xhtml<br><br>I can access this out of the box using this servlet path<br><br>/resources/property/display.jsf<br><br>So developers will unknowningly be adding new public pages to their application (although certainly broken in part) by creating composite components.<br>
<br>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<br><br>#1. Don't allow view IDs to be referenced directly under the /resources/* path.<br>
#2. Make the default resources path /WEB-INF/resources<br><br>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.<br>
<br>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.<br><br>-Dan<br><br>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).<br>
<br><div class="gmail_quote">On Mon, Apr 13, 2009 at 3:01 PM, Ed Burns <span dir="ltr"><<a href="mailto:Ed.Burns@sun.com">Ed.Burns@sun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>>>>> On Fri, 10 Apr 2009 15:21:42 -0400, Dan Allen <<a href="mailto:dan.j.allen@GMAIL.COM">dan.j.allen@GMAIL.COM</a>> said:<br>
<br>
DA> Another question came up at the JSF 2.0 presentation last night, this one<br>
DA> about composite components.<br>
<br>
DA> Can composite component namespaces/directories have multiple nested<br>
DA> directories? Same question with resource locations?<br>
DA> <a href="http://java.sun.com/jsf/composite/storefront/form/" target="_blank">http://java.sun.com/jsf/composite/storefront/form/</a><br>
<br>
The way we agreed to do this was the following syntax in a<br>
facelet-taglibraryA.xml file:<br>
<br>
<facelet-taglib><br>
<namespace><a href="http://domain.com/path" target="_blank">http://domain.com/path</a></namespace><br>
<composite-library-name>compositeTest</composite-library-name><br>
</facelet-taglib><br>
<br>
And this in a facelet-taglibraryB.xml file<br>
<br>
<facelet-taglib><br>
<namespace><a href="http://domain.com/path/nested" target="_blank">http://domain.com/path/nested</a></namespace><br>
<composite-library-name>compositeTestNested</composite-library-name><br>
</facelet-taglib><br>
<br>
Yes, you are correct that the resource naming scheme prevents nested<br>
resource libraries. Nested resource libraries were not on the list of<br>
requirements when we designed this feature back in November of 2007. We<br>
will not accept this requirement change at this point.<br>
<font color="#888888"><br>
Ed<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a href="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</a><br><br>NOTE: While I make a strong effort to keep up with my email on a daily<br>basis, personal or other work matters can sometimes keep me away<br>
from my email. If you contact me, but don't hear back for more than a week,<br>it is very likely that I am excessively backlogged or the message was<br>caught in the spam filters. Please don't hesitate to resend a message if<br>
you feel that it did not reach my attention.<br>