Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.3.0-rc1
-
None
-
None
Description
During a RenderRequest an encodeRedirectURL() can occur if a Wicket url doesn't match the Wicket filter path (fully).
The WicketPortlet caters for this situation by trapping the redirect and validate if it targets this Wicket Filter path and then simply reinvoke the rendering for it.
The encoding in that situation really isn't needed.
For ResourceRequests, this is a different matter: although encodeRedirect isn't supported by JSR-168, for ResourceRequest it is going to be supported by JSR-286.
So, ResourceRequests handling, through the PortletResourceURLFactory and for a JSR-168 container served over a RenderRequest, should allow encodeRedirectURL, even when run on a JSR-168 container.
For ActionRequests, WicketPortlet already properly handed this.
The current implementation in o.a.w.protocol.http.portlet.PortletServletResponseWrapper doesn't cater for the RenderRequest/ResourceRequest situations in that it simply delegated to the wrapped response.
On Jetspeed-2, this still works as its less strictly checking the Portlet API requirements for this situation (which aren't formally tested by the Portlet TCK either).
On Liferay though this fails as it does implements the JSR-168 PLT.16.3.3 cxxxviii check which requires that a null value be returned from encodeRedirectURL (or encodedRedirectUrl).
To solve this issue, I'll implement the following fix:
- moving the encodeRedirectURL and encodeRedirectUrl methods in o.a.w.protocol.http.portlet.PortletActionServletResponseWrapper to its parent PortletServletResponseWrapper.
- in PortletServletResponseWrapper, call super.encodeRedirectURL and if it returns null return the initial url value, otherwise the returned value.