portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Resolved: (JS2-1231) Ensure expired (portal) sessions are properly invalidated/recreated
Date Wed, 12 Jan 2011 16:14:49 GMT

     [ https://issues.apache.org/jira/browse/JS2-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Ate Douma resolved JS2-1231.

    Resolution: Fixed

I've added new PortalSessionValidationFilter which you can configure in the portal/jetspeed
web.xml as follows:


The PortalSessionValidationFilter does all its work through: public static HttpSession getValidSession(HttpServletRequest

I've also added calling this method to the default provided Portal login filters PortalFilter
and ShibbolethPortalFilter in which case you don't need to add the above filter separately
(but it won't hurt either). 

> Ensure expired (portal) sessions are properly invalidated/recreated
> -------------------------------------------------------------------
>                 Key: JS2-1231
>                 URL: https://issues.apache.org/jira/browse/JS2-1231
>             Project: Jetspeed 2
>          Issue Type: Improvement
>          Components: Components Core
>    Affects Versions: 2.2.1
>         Environment: Websphere 6.1, possibly others too
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>             Fix For: 2.2.2
> On certain web containers and especially Websphere, expired session are cleaned up in
a background job which might sometimes take several seconds before executed.
> During that "interval" period, incoming requests trying to access such a session might
actually still "see" it, but be confronted with a IllegalStateException when trying to use/access
session attributes.
> And, in portal environments which use cross-context dispatching across multiple web applications
with individual background cleanup of each their sessions, this all might become very tricky
to deal with without being hit by such IllegalStateExceptions.
> To prevent this potential problem, I'll add a new static utility method which will check
a (servlet) session if it might already be expired (time-wise) and then invalidate/recreate
it (optionally).
> This logic already is used within Pluto PortletRequestImpl.getPortletSession(boolean
create) but that only executes on portlet application level, and actually in some situations
makes things worse if a (also time-wise expired) portal session is kept "alive".
> By ensuring this (portal) session check is run at the earliest stage within the portal,
combined with the Jetspeed PortalSessionManager handling, time-wise expired (portal) sessions
will be cleaned up automatically first, as well as possible portlet application sessions too
(thanks to the PortalSessionManager logic).
> The best "place" to put this check will be within a top level filter mapped to /*, e.g.
like within the Jetspeed PortalFilter. 
> But as not all Jetspeed installations will need/use the Jetspeed PortalFilter (using
default container managed security instead), I'll create a new SessionValidationFilter too
and wire that in the default Portal web.xml.
> I also will add the same logic to the Jetspeed PortalFilter, so for those using (only)
that the same logic will be performed.
> Note: having both Filters in place doesn't really hurt either: the check will be efficient
if/after a session is (re)created anew.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message