[PLUTO-727] PortletSession invalidated in the HEADER_PHASE gets recycled and reused in the RENDER_PHASE

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.0, 3.0.1
• Fix Version/s: 3.1.0
• Component/s: portlet container
• Assignee: Neil Griffin (Inactive)
• Reporter: Neil Griffin (Inactive)
• Created: 21/Aug/18 20:19
• Updated: 14/Dec/22 14:37
• Resolved: 22/Aug/18 00:34

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:

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
        }
    }
}

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 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 that describe the workaround.