[
https://issues.apache.org/jira/browse/PLUTO-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin updated PLUTO-727:
-------------------------------
Description:
As shown in the following example, session attributes set in the
{{HEADER_PHASE}} should not be available in the subsequent {{RENDER_PHASE}} if
the {{PortletSession}} is invalidated in the {{HEADER_PHASE}}:
{code:java|title=MyPortlet.java}
public class MyPortlet extends GenericPortlet {
@Override
public void renderHeaders(HeaderRequest headerRequest, HeaderResponse
headerResponse) {
PortletSesson portletSession = headerRequest.getPortletSession();
portletSession.setAttribute("foo", "1234");
portletSession.invalidate();
}
@Override
public void doView(RenderRequest renderRequest, RenderResponse
renderResponse) {
PortletSesson portletSession = headerRequest.getPortletSession();
String foo = (String) portletSession.getAttribute("foo");
if (foo == null) {
// Correct
}
else {
// Incorrect
}
}
}
{code}
However, due to a cross-context issue incompatibility between Apache Pluto and
Apache Tomcat, the PortletSession invalidated in the {{HEADER_PHASE}} gets
recycled and reused in the {{RENDER_PHASE}}.
The problem stems from a [special cross-context case found in Tomcat's
ApplicationHttpRequest.java
class|https://github.com/apache/tomcat/blob/TOMCAT_8_0_0/java/org/apache/catalina/core/ApplicationHttpRequest.java#L541-L542]
that recycles {{HttpSession}} objects even if they were previously invalidated.
The workaround is to keep track of invalidated {{HttpSession}} identifiers in
Apache Pluto and to clear the session attributes if Tomcat produces an
invalidated/recycled {{HttpSession}}.
A similar problem of was reported in PLUTO-436 which required caused the
developer to add [comments in
PortletRequestContextImpl.java|https://github.com/apache/portals-pluto/blob/pluto-3.0.1/pluto-portal-driver-impl/src/main/java/org/apache/pluto/driver/services/container/PortletRequestContextImpl.java#L370-L377]
that describe the workaround.
was:
As shown in the following example, session attributes set in the
{{HEADER_PHASE}} should not be available in the subsequent {{RENDER_PHASE}} if
the {{PortletSession}} is invalidated in the {{HEADER_PHASE}}:
{code:java|title=MyPortlet.java}
public class MyPortlet extends GenericPortlet {
@Override
public void renderHeaders(HeaderRequest headerRequest, HeaderResponse
headerResponse) {
PortletSesson portletSession = headerRequest.getPortletSession();
portletSession.setAttribute("foo", "1234");
portletSession.invalidate();
}
@Override
public void doView(RenderRequest renderRequest, RenderResponse
renderResponse) {
PortletSesson portletSession = headerRequest.getPortletSession();
String foo = (String) portletSession.getAttribute("foo");
if (foo == null) {
// Correct
}
else {
// Incorrect
}
}
}
{code}
However, due to a cross-context issue incompatibility between Apache Pluto and
Apache Tomcat, the PortletSession invalidated in the {{HEADER_PHASE}} gets
recycled and reused in the {{RENDER_PHASE}}.
The problem stems from a [special cross-context case found in Tomcat's
ApplicationHttpRequest.java
class|https://github.com/apache/tomcat/blob/TOMCAT_8_0_0/java/org/apache/catalina/core/ApplicationHttpRequest.java#L541-L542]
that recycles {{HttpSession}} objects even if they were previously invalidated.
The workaround is to keep track of invalidated {{HttpSession}} identifiers in
Apache Pluto and to clear the session attributes if Tomcat produces an
invalidated/recycled {{HttpSession}.
A similar problem of was reported in PLUTO-436 which required caused the
developer to add [comments in
PortletRequestContextImpl.java|https://github.com/apache/portals-pluto/blob/pluto-3.0.1/pluto-portal-driver-impl/src/main/java/org/apache/pluto/driver/services/container/PortletRequestContextImpl.java#L370-L377]
that describe the workaround.
> PortletSession invalidated in the HEADER_PHASE gets recycled and reused in
> the RENDER_PHASE
> -------------------------------------------------------------------------------------------
>
> Key: PLUTO-727
> URL: https://issues.apache.org/jira/browse/PLUTO-727
> Project: Pluto
> Issue Type: Bug
> Components: portlet container
> Affects Versions: 3.0.0, 3.0.1
> Reporter: Neil Griffin
> Assignee: Neil Griffin
> Priority: Major
> Fix For: 3.0.2
>
>
> As shown in the following example, session attributes set in the
> {{HEADER_PHASE}} should not be available in the subsequent {{RENDER_PHASE}}
> if the {{PortletSession}} is invalidated in the {{HEADER_PHASE}}:
> {code:java|title=MyPortlet.java}
> public class MyPortlet extends GenericPortlet {
> @Override
> public void renderHeaders(HeaderRequest headerRequest, HeaderResponse
> headerResponse) {
> PortletSesson portletSession = headerRequest.getPortletSession();
> portletSession.setAttribute("foo", "1234");
> portletSession.invalidate();
> }
> @Override
> public void doView(RenderRequest renderRequest, RenderResponse
> renderResponse) {
> PortletSesson portletSession = headerRequest.getPortletSession();
> String foo = (String) portletSession.getAttribute("foo");
> if (foo == null) {
> // Correct
> }
> else {
> // Incorrect
> }
> }
> }
> {code}
> However, due to a cross-context issue incompatibility between Apache Pluto
> and Apache Tomcat, the PortletSession invalidated in the {{HEADER_PHASE}}
> gets recycled and reused in the {{RENDER_PHASE}}.
> The problem stems from a [special cross-context case found in Tomcat's
> ApplicationHttpRequest.java
> class|https://github.com/apache/tomcat/blob/TOMCAT_8_0_0/java/org/apache/catalina/core/ApplicationHttpRequest.java#L541-L542]
> that recycles {{HttpSession}} objects even if they were previously
> invalidated.
> The workaround is to keep track of invalidated {{HttpSession}} identifiers in
> Apache Pluto and to clear the session attributes if Tomcat produces an
> invalidated/recycled {{HttpSession}}.
> A similar problem of was reported in PLUTO-436 which required caused the
> developer to add [comments in
> PortletRequestContextImpl.java|https://github.com/apache/portals-pluto/blob/pluto-3.0.1/pluto-portal-driver-impl/src/main/java/org/apache/pluto/driver/services/container/PortletRequestContextImpl.java#L370-L377]
> that describe the workaround.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
