Java Reference
In-Depth Information
JSF expresssion language could be utilized in-place of the static value for the contracts attribute in order to
dynamically determine the name of the template to use. In this scenario, the value of the contracts annotation could
be bound to a backing bean value, such as the following demonstrates:
<f:view contracts="#{myBean.chosenTemplate}">
...
</f:view>
It is also possible to statically define the templates within the
faces-config.xml
configuration file, associating
a specified template to a URL path. To use this solution, add a
<resource-library-contracts>
section within
the
<application>
configuration of the
faces-config.xml
. List each resource mapping within the
<resource-library-contracts>
section, mapping the templates that reside within the application's contracts directory
to static URLs. The following is an excerpt from the
faces-config.xml
file, which ships with the topic sources. The excerpt
demonstrates how to facilitate a static URL mapping for two different templates named “mocha” and “blanco”.
<application>
<resource-library-contracts>
<contract-mapping>
<url-pattern>/chapter02/blanco/*</url-pattern>
<contracts>blanco</contracts>
</contract-mapping>
<contract-mapping>
<url-pattern>/chapter02/mocha/*</url-pattern>
<contracts>mocha</contracts>
</contract-mapping>
</resource-library-contracts>
</application>
The full multi-templating implementation that was planned for inclusion in JSF 2.2 was cut from the final
specification. However, the resource library contracts implementation, which is a scaled-down version of the
previously planned implementation, is a step in the right direction.
Security Enhancements
The JSF 2.2 API includes security enhancements, and one of the most prominent of those is the ability to prevent
cross-site forgery. It is possible for someone to alter a web site in such a way that when users input information into an
application, they are redirected to some harmful server resource where information can be compromised. Oftentimes
web site users do not even know that they've been redirected and end up providing personal information to a malicious
site. JSF takes measures to prevent this type of attack because state is saved on the server side instead of on a client.
With the JSF 2.2 release, additional and stricter protection has been provided against this type of attack. By
default, all postback requests are encrypted. If the page is not a postback request, then the following process occurs:
1.
ViewHandler
looks to see whether the view is listed within the
<protected-views>
element. If so, then the request is processed normally.
2.
If the view is not listed under
<protected-views>
, the
ViewHandler
looks at the response
header to determine whether the request is coming from another view within that same
application. If so, then the request is processed.
3.
If the request header is not present, then the
ViewHandler
checks to see whether there
is a
ResponseStateManager.NON_POSTBACK_VIEW_TOKEN_PARAM
available. This query
parameter should be present, by default, if the view is valid.
