I realized after sending that the /resources path is used for serving publicly accessible resources such as JavaScript libraries and CSS files. Obviously, that is fine...so consider my concern in regards to composite components only and their placement. To extend my point, there is a distinct difference between public resources and protected ones. Composite components are protected resources. So even using the same folder name, one at the web root (public resources) and one inside WEB-INF (composite components and artifacts) is a reasonable, yet consistent, suggestion.<br>
<br>-Dan<br><br><div class="gmail_quote">On Sun, Apr 26, 2009 at 2:02 AM, Dan Allen <span dir="ltr"><<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.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;">
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" target="_blank">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" target="_blank">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" target="_blank">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br>
<a href="http://in.relation.to/Bloggers/Dan" target="_blank">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>
</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>