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

[Martin Marinschek]

I absolutely agree with Dan - we need to protect this.

regards,

Martin

On 4/26/09, Dan Allen <dan.j.allen at gmail.com> wrote:
> 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.
>
> -Dan
>
> On Sun, Apr 26, 2009 at 2:02 AM, Dan Allen <dan.j.allen at gmail.com> wrote:
>
>> 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.
>>
>
>
>
> --
> 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.
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces