[jira] [Updated] (PLUTO-727) PortletSession invalidated in the HEADER_PHASE gets recycled and reused in the RENDER_PHASE

     [ 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 = renderRequest.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 = renderRequest.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)