On Thu, May 19, 2011 at 12:30 AM, [email protected] <[email protected]> wrote: >> >> In the meantime, I suppose that in the clearRunAsIdentities() method, >> we could catch any resulting InvalidSessionException and ignore it. >> Please open a Jira issue if you feel that this should be the case. >> > I believe that there is no meaning to removing an attribute in an > invalidated session since de facto it does not contain any values.
How do you determine if a session is invalid before using it today (in a standard servlet container application)? >> However, I contend that it is more correct to address the underlying >> issue of this - that you're explicitly invalidating the session before >> calling login. >> > Invalidating a session is something that a user can do in a servlet > application. I consider it to be problematic if shiro is failing and this > failure is presented to the use with an intimidating and so esoteric error > message. I do not know whether invalidating a session is bad programming > practice and I would really be greatfull if you could elaborate a little > bit more on that. I wasn't indicating that your behavior is incorrect - only stating that the root cause of Shiro's failure was that you called httpSession.invalidate() on a servlet container session and Shiro didn't 'know' about it. I consider this a Shiro bug - could you please create a Jira issue indicating your problem so we can address it? > Well at the moment our application is written without shiro using native > http sessions and I tried to start integrating it and I got this error at my > first call at subject.login(). Although I still believe this is a bug for this particular scenario, the quick fix is to call subject.logout() instead of httpSession.invalidate() - Shiro will invalidate the session automatically for you. That should get you going again until the bug can be addressed. Can you please create an issue so this isn't lost? Best regards, Les
