Here is a previous thread on this topic which includes some links as to how uPortal deals with this issue:

http://old.nabble.com/Invalidating-all-portlet-sessions-td18386578.html

-Eric

Brett Randall wrote:
Yes Ate is correct, and also here's a couple of likely links to Jetspeed and Liferay issue trackers where I believe they have dealt with the same requirement you are trying to deal with:

http://issues.apache.org/jira/browse/JS2-582
http://issues.liferay.com/browse/LEP-1466

I've not reviewed those issues, but I can image that the Portal context needs to propagate the session invalidation to the Portlet context.

Brett

On Wed, Nov 18, 2009 at 8:26 PM, Ate Douma <[email protected] <mailto:[email protected]>> wrote:

    Portlet 2.0 spec PLT.18.4 (and for that matter the whole of the
    Portlet spec) *only* talks about the *Portlet* application, not
    the *Portal* application.
    This means, the portlet *container* is required to invalidate the
    servlet (application) session when the portlet session is
    invalidated, and this is properly implemented in the Pluto container.
    You should not confuse this with the (limited) behavior of the
    Pluto *Portal* Driver, which primarily purpose is only to serve as
    testbed for the Pluto container, not a full blown, production
    ready, portal.
    Handling logout *across* portlet applications hosted by the Pluto
    Portal Driver simply isn't implemented as it not needed for
    *testing* the Pluto Container itself.

    The Pluto Portal Driver, while actually used by some for
    production purposes, really is not targeted nor maintained for
    such usages.

    If you need such functionality (and/or similar production quality
    features like persistence, better (session) navigation state/url
    handling, etc., etc.) you either have to add this yourself or
    probably better switch using a full blown portal like Apache
    Jetspeed-2 or others which does provide all such features.

    HTH,

    Ate


    hub wrote:

        Brett,
        After logout / login I see the same session attributes as I
        set before in
        the portlet session.
        I noticed that my, "valueUnbound()" method for attributes in
        the portlet
        session is not called for the cleanup I need to do on logout /
        "portal
        session invalidation". I then set portlet session expiration
        time to a short
        period to check, if valueUnbound() is called at all, ... it
        is, also on
        application shutdown.
        The session.invalidate() on logout is run in a jsp in "portal
        context".
        After login with different username I have a different
        principal in the
        portlet session, but same session attributes as set before.


        javabrett wrote:

            If the HttpSession object is invalidated, the
            PortletSession object must
            also be invalidated by the portlet container.


        I read the same here for JSR 168:
        
http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=3131

        I have set emptySessionPath="true" in server.xml.
        running on JBoss GA 4.2.2, Tomcat version is 6.0.20


        Thank you
        hub


        javabrett wrote:

            According to Portlet 2.0 spec PLT.18.4:

               If the HttpSession object is invalidated, the
            PortletSession object
            must
            also be invalidated by the portlet container.

            How do you detect that your portlet sessions are not being
            invalidated?

            Brett

            On Tue, Nov 17, 2009 at 10:09 PM, hub <[email protected]
            <mailto:[email protected]>> wrote:

                Hello,
                How do I invalidate all portlet sessions on logout?

                in my logout.jsp in the portal I do the following
                <%
                  session.invalidate();
                %>

                This invalidates the "portal" session but my portlet
                sessions are not
                invalidated.




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to