Hi,
On Tue, Feb 24, 2015 at 11:26 AM, Frank Caputo <frank_at_frankcaputo.de> wrote:
> Hi,
>
> IMO 1359 brings no benefit to the spec. It just adds complexity to the whole resource handling, which is already complicated enough.
>
> Arjan, can you please explain a little bit more, what are the benefits?
First of all, please note that 1359 was split off from 1099 to
approach a bigger problem in small steps.
This problem that I identified is two fold.
The first is that in the default configuration JSF now has a *source
code exposure vulnerability*. As someone who is engaged with both
security and the web layer, this is something that has been bugging me
for quite a while. The problem is that with the default FacesServlet
mapping of *.jsf, /faces/* and *.faces, and using Facelets, one can
often just request [host]/[page name].xhtml and get to see the source
of the Facelet.
This may or may not reveal anything, but too often it does. Comments
are still in that source as well, since it actually shows the source
file directly (not going through the FacesServlet it really is the
bare source). I've tested this on a number of well known and some
lesser known sites using JSF and more than a few indeed allowed me to
see their source.
There are several possible workarounds for this problem, of which one
is to have views inside a /views folder in WEB-INF. WEB-INF is not
world readable, so directly accessing the .xhtml files, regardless of
what mapping is used is not possible. Such folder would also be future
proof. If a new VDL would use another file extension, say .fvw, then
these would be automatically safe as well.
The second problem is that in Facelets top level views, includes,
templates, etc all have the same extension; .xhtml. The runtime cannot
automatically make a distinction between what are top level views, and
what are other Facelets artefacts and in fact what are just files with
an .xhtml extension not being related to JSF at all. This again
introduces some security concerns, like /resources/mycomposite.xhtml
being requestable via a URL, even when it's not intended to be
requested as such. Furthermore, if we don't know what is a view and
what is not, other types of processing that should be done on views
only is not possible either. One example of such processing is
extensionless mapping, such as mentioned in the thread about URL
mapping.
In both cases, the /views directory is not a feature by itself, but an
enabler for other things; security, extensionless mapping and more
advanced processing in general.
Hope this clears things up.
Kind regards,
Arjan Tijms
>
> Ciao Frank
>
>> Am 23.02.2015 um 23:05 schrieb Edward Burns <edward.burns_at_oracle.com>:
>>
>>>>>>> On Fri, 20 Feb 2015 09:56:02 -0600, manfred riem <manfred.riem_at_oracle.com> said:
>>
>> MR> Hi all,
>> MR> Unless there are any other objections voiced before EOB next Friday
>> MR> (2/27) I am going ahead with this contribution from Arjan (which from a
>> MR> security aspect is a good thing). Note this one will be behind the 2.3
>> MR> switch.
>>
>> Looking at both JIRA issues, 1099 and 1359, I would like to close 1099
>> as WONTFIX and proceed with 1359. My reason for this preference is that
>> 1099 is a broader scope than 1359.
>>
>> Ed
>> --
>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>> | 10 days til DevNexus 2015
>> | 20 days til JavaLand 2015
>> | 30 days til CONFESS 2015
>