You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by bu...@apache.org on 2020/01/11 16:19:53 UTC

svn commit: r1055136 [2/2] - in /websites/production/tapestry/content: cache/main.pageCache component-rendering.html content-type-and-markup.html dom.html https.html request-processing.html response-compression.html security.html url-rewriting.html

Modified: websites/production/tapestry/content/security.html
==============================================================================
--- websites/production/tapestry/content/security.html (original)
+++ websites/production/tapestry/content/security.html Sat Jan 11 16:19:52 2020
@@ -104,7 +104,7 @@
                 <span class="icon aui-icon content-type-page" title="Page">Page:</span>        </div>
 
         <div class="details">
-                        <a  href="integrating-with-spring-framework.html">Integrating with Spring Framework</a>
+                        <a  href="https.html">HTTPS</a>
                 
                         
                     </div>
@@ -113,7 +113,7 @@
                 <span class="icon aui-icon content-type-page" title="Page">Page:</span>        </div>
 
         <div class="details">
-                        <a  href="https.html">HTTPS</a>
+                        <a  href="integrating-with-spring-framework.html">Integrating with Spring Framework</a>
                 
                         
                     </div>
@@ -132,7 +132,7 @@
 
 <p><br clear="none"></p><h2 id="Security-HTTPS-onlyPages">HTTPS-only Pages</h2><p>Main Article: <a  href="https.html">HTTPS</a></p><p>Tapestry provides several annotations and configuration settings that you can use to&#160;<span>ensure that all access to certain pages (or all pages) occurs only via the encrypted HTTPS protocol</span><span>. See&#160;<a  href="https.html">HTTPS</a> for details.</span></p><h2 id="Security-ControllingPageAccess"><span>Controlling Page Access</span></h2><p><br clear="none"></p><div class="navmenu" style="float:right; background:#eee; margin:3px; padding:0 1em">
 <p>    <strong>JumpStart Demo:</strong><br clear="none">
-    <span class="nobr"><a  class="external-link" href="http://jumpstart.doublenegative.com.au/jumpstart/examples/infrastructure/protectingpages" rel="nofollow">Protecting Pages<sup><img align="middle" class="rendericon" src="/images/confluence/icons/linkext7.gif" height="7" width="7" alt="" border="0"></sup></a></span></p></div><p><span>For simple access control needs, you can contribute a&#160;<span><a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ComponentRequestFilter.html">ComponentRequestFilter</a> with your custom logic that decides which pages should be accessed by which users. The <a  class="external-link" href="https://tapestry-app.apache.org/hotels/">Tapestry Hotel Booking </a>app demonstrates this approach with an <code>@AnonymousAccess</code> annotation along with a ComponentRequestFilter named&#160;<code>AuthenticationFilter.java</code>. The filter enforces security by intercepting all requests to pages that don't 
 have that annotation, and it redirects those requests to the login page. <a  class="external-link" href="http://jumpstart.doublenegative.com.au/jumpstart/examples/infrastructure/protectingpages" rel="nofollow">JumpStart</a> has a similar demo.<br clear="none"></span></span></p><p><br clear="none"></p><p><span>For more advanced needs see the Security Framework Integration section below.</span></p><h2 id="Security-White-listedPages">White-listed Pages</h2><p>Pages whose component classes are annotated with&#160;@<a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/WhitelistAccessOnly.html">WhitelistAccessOnly</a>&#160;will only be displayed to users (clients) that are on the&#160;<em>whitelist</em>. By default the whitelist consists only of clients whose fully-qualified domain name is "localhost" (or the IP address equivalent, 127.0.0.1 or 0:0:0:0:0:0:0:1),&#160;but you can customize this by contributing to the ClientWhitelist ser
 vice&#160;in your application's module class (usually AppModule.java):</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>AppModule.java (partial) &#8211; simple inline example</b></div><div class="codeContent panelContent pdl">
+    <span class="nobr"><a  class="external-link" href="http://jumpstart.doublenegative.com.au/jumpstart/examples/infrastructure/protectingpages" rel="nofollow">Protecting Pages<sup><img align="middle" class="rendericon" src="/images/confluence/icons/linkext7.gif" height="7" width="7" alt="" border="0"></sup></a></span></p></div><span>For simple access control needs, you can contribute a&#160;<span><a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ComponentRequestFilter.html">ComponentRequestFilter</a> with your custom logic that decides which pages should be accessed by which users. The <a  class="external-link" href="https://tapestry-app.apache.org/hotels/">Tapestry Hotel Booking </a>app demonstrates this approach with an <code>@AnonymousAccess</code> annotation along with a ComponentRequestFilter named&#160;<code>AuthenticationFilter.java</code>. The filter enforces security by intercepting all requests to pages that don't hav
 e that annotation, and it redirects those requests to the login page. <a  class="external-link" href="http://jumpstart.doublenegative.com.au/jumpstart/examples/infrastructure/protectingpages" rel="nofollow">JumpStart</a> has a similar demo.<br clear="none"></span></span><p><br clear="none"></p><p><span>For more advanced needs see the Security Framework Integration section below.</span></p><h2 id="Security-White-listedPages">White-listed Pages</h2><p>Pages whose component classes are annotated with&#160;@<a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/WhitelistAccessOnly.html">WhitelistAccessOnly</a>&#160;will only be displayed to users (clients) that are on the&#160;<em>whitelist</em>. By default the whitelist consists only of clients whose fully-qualified domain name is "localhost" (or the IP address equivalent, 127.0.0.1 or 0:0:0:0:0:0:0:1),&#160;but you can customize this by contributing to the ClientWhitelist service&#1
 60;in your application's module class (usually AppModule.java):</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>AppModule.java (partial) &#8211; simple inline example</b></div><div class="codeContent panelContent pdl">
 <pre class="syntaxhighlighter-pre" data-syntaxhighlighter-params="brush: java; gutter: false; theme: Default" data-theme="Default">    @Contribute(ClientWhitelist.class)
     public static void provideWhitelistAnalyzer(OrderedConfiguration&lt;WhitelistAnalyzer&gt; configuration)
     {
@@ -145,9 +145,9 @@
             }
         }, "before:*");
     }</pre>
-</div></div><p><br clear="none"></p><p>Sometimes, in production, a firewall or proxy may make it look like the client web browser originates from localhost, with the consequence that whitelisted pages may be visible to all users. See the&#160;<a  href="security-faq.html">Security FAQ</a> for how to deal with this.</p><h2 id="Security-AssetSecurity">Asset Security</h2><p>Main Article:&#160;<a  href="security.html">Security</a></p><p class="confluence-link">Tapestry serves assets (static content such as CSS files, images, and JavaScript, many of which are on the classpath alongside your compiled class files) to the client.&#160;Because of this, great care has gone into ensuring that certain file types cannot be served to the client. By default, file ending with ".class', ".tml" and ".properties" can be served to the client only if the request includes the file's MD5 checksum. As you would expect, that blacklist can be extended. See <a  href="assets.html">Assets</a> for more informatio
 n.</p><h2 id="Security-ProtectingSerializedObjectDataontheClient">Protecting Serialized Object Data on the Client</h2><p><span style="color: rgb(0,0,0);">As of version 5.3.6, Tapestry integrates a&#160;</span><a  class="external-link" href="http://en.wikipedia.org/wiki/HMAC" rel="nofollow" style="text-decoration: underline;text-align: justify;">hash-based message authentication code</a><span style="color: rgb(0,0,0);">&#160;(HMAC) into serialized Java object data that it sends to the client (generally, this means the&#160;</span><code style="text-align: justify;">t:formdata</code><span style="color: rgb(0,0,0);">&#160;hidden field used by the Form component). This ensures that the hidden binary object data is guaranteed to be unaltered when it returns to the server upon form (or AJAX) submission. The HMAC pass phrase is set using the&#160;<a  href="configuration.html">tapestry.hmac-passphrase</a> configuration symbol. If you don't set that value, you'll see a warning message in the 
 browser, like this:&#160;</span></p><div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
+</div></div><p><br clear="none"></p><p>Sometimes, in production, a firewall or proxy may make it look like the client web browser originates from localhost, with the consequence that whitelisted pages may be visible to all users. See the&#160;<a  href="security-faq.html">Security FAQ</a> for how to deal with this.</p><h2 id="Security-AssetSecurity">Asset Security</h2><p>Main Article:&#160;<a  href="https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=85462227">Security</a></p><p class="confluence-link">Tapestry serves assets (static content such as CSS files, images, and JavaScript, many of which are on the classpath alongside your compiled class files) to the client.&#160;Because of this, great care has gone into ensuring that certain file types cannot be served to the client. By default, file ending with ".class', ".tml" and ".properties" can be served to the client only if the request includes the file's MD5 checksum. As you would expect, that blacklist can be extende
 d. See <a  href="assets.html">Assets</a> for more information.</p><h2 id="Security-ProtectingSerializedObjectDataontheClient">Protecting Serialized Object Data on the Client</h2><p><span style="color: rgb(0,0,0);">As of version 5.3.6, Tapestry integrates a&#160;</span><a  class="external-link" href="http://en.wikipedia.org/wiki/HMAC" rel="nofollow" style="text-decoration: underline;text-align: justify;">hash-based message authentication code</a><span style="color: rgb(0,0,0);">&#160;(HMAC) into serialized Java object data that it sends to the client (generally, this means the&#160;</span><code style="text-align: justify;">t:formdata</code><span style="color: rgb(0,0,0);">&#160;hidden field used by the Form component). This ensures that the hidden binary object data is guaranteed to be unaltered when it returns to the server upon form (or AJAX) submission. The HMAC pass phrase is set using the&#160;<a  href="configuration.html">tapestry.hmac-passphrase</a> configuration symbol. If yo
 u don't set that value, you'll see a warning message in the browser, like this:&#160;</span></p><div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
 <pre>The symbol 'tapestry.hmac-passphrase' has not been configured. This is used to configure hash-based message authentication of Tapestry data stored in forms, or in the URL. You application is less secure, and more vulnerable to denial-of-service attacks, when this symbol is not configured.</pre>
-</div></div><p><span style="color: rgb(0,0,0);">The solution is to set the tapestry.hmac-passphrase to some value (any fixed, private string, such as 30 to 40 random-looking characters, will do) in your application's module class (usually AppModule.java).</span></p><h2 id="Security-CrossSiteRequestForgery(CSRF)"><span style="color: rgb(83,145,38);">Cross Site Request Forgery (CSRF)</span></h2><p>Cross Site Request Forgery is a type of security vulnerability in which legitimate, authorized users may be made to unwittingly submit malicious requests to your web application.</p><p><a  class="external-link" href="https://github.com/porscheinformatik/tapestry-csrf-protection" rel="nofollow">Tapestry-csrf-protection</a>&#160;is a 3rd party module that has several features for preventing CSRF attacks. It protects all&#160;<span>component event handlers (event links, forms, etc.) by adding a&#160;</span><span>CSRF token to event links and adds a CSRF token as a hidden field to all forms.&#16
 0;</span><span>Tokens are generated on a per-session basis.</span></p><h2 id="Security-SecurityFrameworkIntegration"><span>Security Framework Integration</span></h2><p>Tapestry does not lock you into a specific authentication/authorization implementation. There are integration modules available for the more popular open source Java security frameworks. A popular choice among Tapestry users is <a  class="external-link" href="http://www.tynamo.org/tapestry-security+guide/" rel="nofollow">tapestry-security (based on Apache Shiro) from Tynamo.org</a>. It is always kept up-to-date with the latest Tapestry versions and offers several supporting security modules (e.g. <a  class="external-link" href="http://www.tynamo.org/tapestry-security-jpa+guide/" rel="nofollow">tapestry-security-jpa</a>, <a  class="external-link" href="http://www.tynamo.org/tynamo-federatedaccounts+guide/" rel="nofollow">tynamo-federatedaccounts</a>). There's also an <a  class="external-link" href="http://www.localhost
 .nu/java/tapestry-spring-security" rel="nofollow">integration module available for Spring Security</a> but lately, it hasn't kept up with the latest versions of Tapestry 5.</p><p>Additional information:</p><ul><li><a  class="external-link" href="http://www.tynamo.org/tynamo-federatedaccounts+guide/" rel="nofollow">Tynamo-federatedaccounts</a>&#160;<span style="color: rgb(0,0,0);">is an add-on to the&#160;</span><a  class="external-link" href="http://www.tynamo.org/tapestry-security+guide/" rel="nofollow">tapestry-security</a><span style="color: rgb(0,0,0);">&#160;module, providing federated (third-party) authentication with Facebook, Twitter or Google.</span></li></ul><ul><li><span>To include OpenID with Spring Security in your application, see the following Wiki entry:&#160;</span><a  class="external-link" href="http://wiki.apache.org/tapestry/Tapestry5HowToSpringSecurityAndOpenId">http://wiki.apache.org/tapestry/Tapestry5HowToSpringSecurityAndOpenId</a></li></ul><h2 id="Security-V
 ulnerabilityDisclosures">Vulnerability Disclosures</h2><h3 id="Security-CVE-2019-0195:FilereadingLeadsJavaDeserializationVulnerability.">CVE-2019-0195: File reading Leads Java Deserialization Vulnerability.</h3><p>Disclosure date:&#160;<a  class="external-link" href="https://lists.apache.org/thread.html/5173c4eed06e2fca6fd5576ed723ff6bb1711738ec515cb51a04ab24@%3Cusers.tapestry.apache.org%3E">September 13th, 2019</a></p><p>Versions affected: all Apache Tapestry versions between 5.4.0, including its betas, and 5.4.3</p><p>Description:&#160;Manipulating classpath asset file URLs, an attacker could guess the path to&#160;a known file in the classpath and have it downloaded. If the attacker&#160;found the file with the value of the tapestry.hmac-passphrase configuration&#160;symbol, most probably the webapp's AppModule class, the value of this&#160;symbol could be used to craft a Java deserialization attack, thus running&#160;malicious injected Java code. The vector would be the t:formda
 ta parameter&#160;from the Form component.</p><p>Mitigation: Upgrade to Tapestry 5.4.5, which is a drop-in replacement for any 5.4.x version.</p><p>Credit: Ricter Zheng</p><h3 id="Security-CVE-2019-0207:ApacheTapestry5.4.2PathTraversalvulnerability">CVE-2019-0207: Apache Tapestry 5.4.2 Path Traversal vulnerability</h3><p>Disclosure date:&#160;<a  class="external-link" href="https://lists.apache.org/thread.html/765be3606d865de513f6df9288842c3cf58b09a987c617a535f2b99d@%3Cusers.tapestry.apache.org%3E">September 13th, 2019</a></p><p>Versions affected: all Apache Tapestry versions between 5.4.0, including its betas, and 5.4.4.</p><p>Description: Tapestry processes assets `/assets/ctx` using classes chain `StaticFilesFilter -&gt; AssetDispatcher -&gt; ContextResource`, which doesn't filter the character `\`, so attacker can perform a path traversal attack to read any files on Windows platform.</p><p>Mitigation: Upgrade to Tapestry 5.4.5, which is a drop-in replacement for any 5.4.x versio
 n.</p><p>Credit: Ricter Zheng</p><h3 id="Security-CVE-2019-10071:NewIssueinFixforCVE-2014-1972">CVE-2019-10071: New Issue in Fix for CVE-2014-1972</h3><p>Disclosure date: <a  rel="nofollow">September 13th, 2019</a></p><p>Versions affected: all Apache Tapestry versions between 5.4.0, including<br clear="none">its betas, and 5.4.3</p><p>Description: The code which checks HMAC in form submissions used<br clear="none">String.equals() for comparisons, which results in a timing side channel for<br clear="none">the comparison of the HMAC signatures. This could lead to remote code<br clear="none">execution if an attacker is able to determine the correct signature for<br clear="none">their payload. The comparison should be done with a constant time algorithm<br clear="none">instead.</p><p>Mitigation: Upgrade to Tapestry 5.4.5, which is a drop-in replacement for any 5.4.x<br clear="none">version.</p><p>Credit:&#160;</p><pre>David Tomaschik of the Google Security Team</pre></div>
+</div></div><p><span style="color: rgb(0,0,0);">The solution is to set the tapestry.hmac-passphrase to some value (any fixed, private string, such as 30 to 40 random-looking characters, will do) in your application's module class (usually AppModule.java).</span></p><h2 id="Security-CrossSiteRequestForgery(CSRF)"><span style="color: rgb(83,145,38);">Cross Site Request Forgery (CSRF)</span></h2><p>Cross Site Request Forgery is a type of security vulnerability in which legitimate, authorized users may be made to unwittingly submit malicious requests to your web application.</p><p><a  class="external-link" href="https://github.com/porscheinformatik/tapestry-csrf-protection" rel="nofollow">Tapestry-csrf-protection</a>&#160;is a 3rd party module that has several features for preventing CSRF attacks. It protects all&#160;<span>component event handlers (event links, forms, etc.) by adding a&#160;</span><span>CSRF token to event links and adds a CSRF token as a hidden field to all forms.&#16
 0;</span><span>Tokens are generated on a per-session basis.</span></p><h2 id="Security-SecurityFrameworkIntegration"><span>Security Framework Integration</span></h2><p>Tapestry does not lock you into a specific authentication/authorization implementation. There are integration modules available for the more popular open source Java security frameworks. A popular choice among Tapestry users is <a  class="external-link" href="http://www.tynamo.org/tapestry-security+guide/" rel="nofollow">tapestry-security (based on Apache Shiro) from Tynamo.org</a>. It is always kept up-to-date with the latest Tapestry versions and offers several supporting security modules (e.g. <a  class="external-link" href="http://www.tynamo.org/tapestry-security-jpa+guide/" rel="nofollow">tapestry-security-jpa</a>, <a  class="external-link" href="http://www.tynamo.org/tynamo-federatedaccounts+guide/" rel="nofollow">tynamo-federatedaccounts</a>). There's also an <a  class="external-link" href="http://www.localhost
 .nu/java/tapestry-spring-security" rel="nofollow">integration module available for Spring Security</a> but lately, it hasn't kept up with the latest versions of Tapestry 5.</p><p>Additional information:</p><ul><li><a  class="external-link" href="http://www.tynamo.org/tynamo-federatedaccounts+guide/" rel="nofollow">Tynamo-federatedaccounts</a>&#160;<span style="color: rgb(0,0,0);">is an add-on to the&#160;</span><a  class="external-link" href="http://www.tynamo.org/tapestry-security+guide/" rel="nofollow">tapestry-security</a><span style="color: rgb(0,0,0);">&#160;module, providing federated (third-party) authentication with Facebook, Twitter or Google.</span></li></ul><ul><li><span>To include OpenID with Spring Security in your application, see the following Wiki entry:&#160;</span><a  class="external-link" href="http://wiki.apache.org/tapestry/Tapestry5HowToSpringSecurityAndOpenId">http://wiki.apache.org/tapestry/Tapestry5HowToSpringSecurityAndOpenId</a></li></ul><h2 id="Security-V
 ulnerabilityDisclosures">Vulnerability Disclosures</h2><h3 id="Security-CVE-2019-0195:FilereadingLeadsJavaDeserializationVulnerability.">CVE-2019-0195: File reading Leads Java Deserialization Vulnerability.</h3><p>Disclosure date:&#160;<a  class="external-link" href="https://lists.apache.org/thread.html/5173c4eed06e2fca6fd5576ed723ff6bb1711738ec515cb51a04ab24@%3Cusers.tapestry.apache.org%3E">September 13th, 2019</a></p><p>Versions affected: all Apache Tapestry versions between 5.4.0, including its betas, and 5.4.3</p><p>Description:&#160;Manipulating classpath asset file URLs, an attacker could guess the path to&#160;a known file in the classpath and have it downloaded. If the attacker&#160;found the file with the value of the tapestry.hmac-passphrase configuration&#160;symbol, most probably the webapp's AppModule class, the value of this&#160;symbol could be used to craft a Java deserialization attack, thus running&#160;malicious injected Java code. The vector would be the t:formda
 ta parameter&#160;from the Form component.</p><p>Mitigation: Upgrade to Tapestry 5.4.5, which is a drop-in replacement for any 5.4.x version.</p><p>Credit: Ricter Zheng</p><h3 id="Security-CVE-2019-0207:ApacheTapestry5.4.2PathTraversalvulnerability">CVE-2019-0207: Apache Tapestry 5.4.2 Path Traversal vulnerability</h3><p>Disclosure date:&#160;<a  class="external-link" href="https://lists.apache.org/thread.html/765be3606d865de513f6df9288842c3cf58b09a987c617a535f2b99d@%3Cusers.tapestry.apache.org%3E">September 13th, 2019</a></p><p>Versions affected: all Apache Tapestry versions between 5.4.0, including its betas, and 5.4.4.</p><p>Description: Tapestry processes assets `/assets/ctx` using classes chain `StaticFilesFilter -&gt; AssetDispatcher -&gt; ContextResource`, which doesn't filter the character `\`, so attacker can perform a path traversal attack to read any files on Windows platform.</p><p>Mitigation: Upgrade to Tapestry 5.4.5, which is a drop-in replacement for any 5.4.x versio
 n.</p><p>Credit: Ricter Zheng</p><h3 id="Security-CVE-2019-10071:NewIssueinFixforCVE-2014-1972">CVE-2019-10071: New Issue in Fix for CVE-2014-1972</h3><p>Disclosure date: <a  rel="nofollow">September 13th, 2019</a></p><p>Versions affected: all Apache Tapestry versions between 5.4.0, including<br clear="none">its betas, and 5.4.3</p><p>Description: The code which checks HMAC in form submissions used<br clear="none">String.equals() for comparisons, which results in a timing side channel for<br clear="none">the comparison of the HMAC signatures. This could lead to remote code<br clear="none">execution if an attacker is able to determine the correct signature for<br clear="none">their payload. The comparison should be done with a constant time algorithm<br clear="none">instead.</p><p>Mitigation: Upgrade to Tapestry 5.4.5, which is a drop-in replacement for any 5.4.x<br clear="none">version.</p><p>Credit:&#160;</p><pre>David Tomaschik of the Google Security Team<br clear="none"><br clear
 ="none"></pre></div>
       </div>
 
       <div class="clearer"></div>

Modified: websites/production/tapestry/content/url-rewriting.html
==============================================================================
--- websites/production/tapestry/content/url-rewriting.html (original)
+++ websites/production/tapestry/content/url-rewriting.html Sat Jan 11 16:19:52 2020
@@ -76,7 +76,7 @@
 
       <div id="content">
                 <div id="ConfluenceContent"><h1 id="URLrewriting-TapestryURLRewritingSupport">Tapestry URL Rewriting Support</h1><div class="confluence-information-macro confluence-information-macro-note"><span class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Starting with Tapestry 5.2, the URLRewriterRule service has been replaced with the new LinkTransformer service. This page needs to be revised to reflect the new API. Meanwhile, please see Igor Drobiazko's <a  class="external-link" href="https://web.archive.org/web/20150906154302/http://blog.tapestry5.de/index.php/2010/09/06/new-url-rewriting-api/" rel="nofollow">excellent blog post on this topic</a>.</p></div></div><p>Since 5.1.0.1, Tapestry has basic support for URL rewriting. Incoming requests and links generated by Tapestry can be rewritten using exactly the same API, based on a chain of <a  class="external-link" href="http://tapes
 try.apache.org/current/apidocs/org/apache/tapestry5/urlrewriter/URLRewriterRule.html">URLRewriterRule</a> interfaces. These rules are executed before all other Tapestry request handling, so your application does not otherwise know that the received request is not the original one.</p><p>Each URL rewriter rule, in its <code>Request process</code>, can choose between returning another <code>Request</code>, effectively rewriting it, or returning the received request unchanged, meaning that this rule does not apply to that request.</p><p>To facilitate <code>Request</code> creation, Tapestry provides the <code>SimpleRequestWrapper</code> class. It wraps a <code>Request</code>, delegating all methods except <code>getPath()</code> and <code>getServerName()</code>. More request wrappers may be added in the future on demand.</p><h2 id="URLrewriting-Configuration">Configuration</h2><p>Tapestry's URL rewriting support is configured by Tapestry-IoC through contribution of a <code>URLRewriterRul
 e</code> to the <code>URLRewriter</code> service. The following example is part of the Tapestry's tests.</p><h2 id="URLrewriting-Simpleexampleofrulechaining">Simple example of rule chaining</h2><p>This example just rewrites all incoming requests to <code>/struts</code> to <code>/tapestry</code>. In your <code>AppModule</code> or any other Tapestry-IoC module class:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">public static void contributeURLRewriter(OrderedConfiguration&lt;URLRewriterRule&gt; configuration)
+<pre class="syntaxhighlighter-pre" data-syntaxhighlighter-params="brush: java; gutter: false; theme: Default" data-theme="Default">public static void contributeURLRewriter(OrderedConfiguration&lt;URLRewriterRule&gt; configuration)
 {
     
     URLRewriterRule rule = new URLRewriterRule() 
@@ -105,7 +105,7 @@
 }
 </pre>
 </div></div><h2 id="URLrewriting-Exampleofrulechaining">Example of rule chaining</h2><p>In your <code>AppModule</code> or any other Tapestry-IoC module class.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">public static void contributeURLRewriter(OrderedConfiguration&lt;URLRewriterRule&gt; configuration)
+<pre class="syntaxhighlighter-pre" data-syntaxhighlighter-params="brush: java; gutter: false; theme: Default" data-theme="Default">public static void contributeURLRewriter(OrderedConfiguration&lt;URLRewriterRule&gt; configuration)
 {
     
     URLRewriterRule rule1 = new URLRewriterRule()
@@ -205,7 +205,7 @@
 }
 </pre>
 </div></div><p>This examples shows the URL rewriting chaining: the first rule rewrites requests to <code>/struts</code> and rewrites them to <code>/jsf</code> and leaves requests to other URLs unchanged. The second rewrites <code>/jsf</code> to <code>/tapestry</code> and the third rewrites <code>/tapestry</code> to <code>/urlrewritesuccess</code>.</p><p>The result is that any request to <code>/struts</code> end up being handled by the same class that handles <code>/urlrewritesuccess</code>, while the browser, the user and Tapestry still sees <code>/struts</code>.</p><p>Note that this applies to rewriting links generated by Tapestry too: a <code>PageLink</code> to the <code>urlrewritesuccess</code> page with an activation context of <code>login</code> (path <code>/urlrewritesuccess/login</code>) will generate an <code>a</code> tag pointing to <code><span class="nolink">http://login.domain.com</span></code>.</p><p>The URLRewriteContext (added in 5.1.0.4) provides additional informatio
 n for rewriting, particularly in the context of rewriting generated link urls. In the following example, we'll reconfigure the url used to render pages. Whereas the previous examples used separate rules for handling inbound and outbound rewriting, this demonstration will utilize a single rule for both scenarios. To simplify the example, we will assume that every page is named "XXXPage" (UserPage, TransactionPage, IndexPage, etc.). This naming convention also means that we don't have to worry about tapestry's auto-stripping of "index" from URLs, because our page would be IndexPage, rather than Index.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">public static void contributeURLRewriter(OrderedConfiguration&lt;URLRewriterRule&gt; configuration)
+<pre class="syntaxhighlighter-pre" data-syntaxhighlighter-params="brush: java; gutter: false; theme: Default" data-theme="Default">public static void contributeURLRewriter(OrderedConfiguration&lt;URLRewriterRule&gt; configuration)
 {
     URLRewriterRule rule = new URLRewriterRule() 
     {
@@ -245,7 +245,7 @@
 
 }
 </pre>
-</div></div><p>In the first part of <code>process</code>, <code>context.isIncoming()</code> determines if the call to <code>process</code> occurred due to an inbound request. If so, the rule reverses the mapping done in the second portion of the method, so tapestry sees the original request.</p><p>The second half of <code>process</code> rewrites only page links by retrieving the logical page name and replacing its occurrence in the url with the shortened form of the link. This code segment demonstrates how the additional information provided by <code>URLRewriteContext</code> can be used to rewrite urls in a generalized manner.</p><p>Note that <code>getPageParameters()</code> will only return non-null when <code>process</code> is called due to page link creation, and <code>getComponentEventParameters()</code> will only return non-null when <code>process</code> is called as a result of creating component event links.</p></div>
+</div></div><p>In the first part of <code>process</code>, <code>context.isIncoming()</code> determines if the call to <code>process</code> occurred due to an inbound request. If so, the rule reverses the mapping done in the second portion of the method, so tapestry sees the original request.</p><p>The second half of <code>process</code> rewrites only page links by retrieving the logical page name and replacing its occurrence in the url with the shortened form of the link. This code segment demonstrates how the additional information provided by <code>URLRewriteContext</code> can be used to rewrite urls in a generalized manner.</p><p>Note that <code>getPageParameters()</code> will only return non-null when <code>process</code> is called due to page link creation, and <code>getComponentEventParameters()</code> will only return non-null when <code>process</code> is called as a result of creating component event links.</p><p></p></div>
       </div>
 
       <div class="clearer"></div>