| (10:09:25 AM) anil_msn: hello Remy. When the session expires, the session listener basically gets a tomcat session facade (that implements httpsession). I was interested in the principal being stored as a note in catalina session. I doubt we will be able to get to the actual catalina session from the facade | (10:10:31 AM) Remy Maucherat: the facade strictly implements the javax API, and thus does not add any custom call to internal structures; the principal can be accessed through other objects (the request, I think) | (10:11:26 AM) Remy Maucherat: so can you use the request instead ? | (10:11:34 AM) anil_msn: for a regular session.invalidation, we are in a path of request. But when the container expires sessions after an hour or so, there is no request | (10:11:46 AM) anil_msn: we are using the request approach for active sessions getting invalidated | (10:12:20 AM) anil_msn: only the case of container expiring sessions | (10:12:51 AM) anil_msn: I think any approach we take will be like a hack | (10:13:13 AM) anil_msn: better ignore the use case (some customer asked for it) | (10:16:32 AM) Remy Maucherat: hum, right, that's interesting stuff, but it's not going to work | (10:17:16 AM) anil_msn: I was thinking about placing the principal after authentication into the http session. But are u saying that the facade will lose it? | (10:17:25 AM) anil_msn: anyway we are not doing the hack | (10:19:33 AM) Remy Maucherat: no, you can put an object in the session as an attribute | (10:20:10 AM) anil_msn: I cannot justify placing the principal in the session attribute map, just to solve one rare use case. | (10:20:22 AM) anil_msn: we recommend session invalidation anyway as a best practice. | (10:23:05 AM) Remy Maucherat: of course, but most likely they can use a filter or listener to do it | (10:24:53 AM) anil_msn: That is a good suggestion. We can provide an ondemand valve to place the principal on the session (only if the customer wants it) and then update our session listener to also look for this principal | (10:25:14 AM) anil_msn: if the customer is so bent on this use case, he can configure this valve that we will provide | (10:27:22 AM) Remy Maucherat: it would be better to use a filter: his application will always need the attribute to run | We can solve it this way (based on a suggestion from Remy): a) We will provide a servlet filter in "org.jboss.web.tomcat.security" called as PrincipalSessionAttributeFilter. This filter has one objective - place the principal from request.getUserPrincipal in the session attribute (if not already present) under a key like JBOSS_PRINCIPAL. This filter should be configured by the user on an on-demand basis. We will not enable this filter by default. (If the customer wants this to be applied to all web apps, he can configure this in web.xml of the jboss tomcat service). b) Update our session binding listener to also look for this JBOSS_PRINCIPAL in the session attribute to flush. Issue: When sessions expire on their own, we do not have any principal handy for the session because we do not have any requests coming in (to be able to pick it up from SecurityAssociation). Hence we need a way to pick the principal off of the session maybe. The Tomcat session does retain the principal in its session. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088485#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...