Hi Ed,
> Am 26.02.2015 um 00:12 schrieb Edward Burns <edward.burns_at_oracle.com>:
>
> Conceptually, I do not look at the Facelet files in a contract as a top
> level view. Thus, I would be in favor of tightening the spec to say
> that Facelet files in a contract must not be loadable as top level
> views.
>
> Frank, are you ok with that?
Unfortunately a customer of mine is using this functionality. They have a contract for mobile clients and they need the possibility to replace complete views. This is the project, from which resource library contracts derived. So I would not delete this functionality.
Another argument against this is the argumentation we followed in 2.2, where we said, a facelet is just a facelet, without any need to differentiate between different purposes of a facelet.
> FC> IMO 1359 brings no benefit to the spec. It just adds complexity to
> FC> the whole resource handling, which is already complicated enough.
>
> Hi Frank, you're right in pointing out 1359-views adds little value.
> Just the same, for the two reasons cited in the following text, I can
> support it.
>
> FC> Arjan, can you please explain a little bit more, what are the benefits?
>
>>>>>> On Tue, 24 Feb 2015 12:03:45 +0100, arjan tijms <arjan.tijms_at_gmail.com> said:
>
> AT> The first is that in the default configuration JSF now has a *source
> AT> code exposure vulnerability*. […]
This was also discussed in 2.2 and we decided to not care about this. Currently ViewResources in Mojarra don’t expose the input stream (which i’d like to see). It is easy to hide facelets.
> AT> The second problem is that in Facelets top level views, includes,
> AT> templates, etc all have the same extension; .xhtml. The runtime cannot
> AT> automatically make a distinction between what are top level views, and
> AT> what are other Facelets artefacts and in fact what are just files with
> AT> an .xhtml extension not being related to JSF at all. This again
> AT> introduces some security concerns, like /resources/mycomposite.xhtml
> AT> being requestable via a URL, even when it's not intended to be
> AT> requested as such.
>
> Strictly speaking, these two items are different aspects of the same
> concern.
See above.
> One other aspect not mentioned is alignment with the MVC spec.
This one is the only valid one for me. Unfortunately I was really busy the last months and didn’t follow the MVC discussions very well. I’ll take a deeper look into this.
@Manfred, can you explain this a little bit?
Ciao Frank