Les Hazlewood-2 wrote: > > On Wed, May 18, 2011 at 6:23 AM, [email protected] > <[email protected]> wrote: >> Update >> >> The error message was rather intimidating and it made me more eager to >> post >> it to the list. After some thought I decided to dig it a little bit more >> myself so I have downloaded the shiro source code and did some debugging. >> >> What I came across is that the error was a side-effect from our existing >> login code where we invalidated the session before our login code to >> protect >> from session stealing attacks. >> >> So the shiro code that tried to remove key >> org.apache.shiro.subject.support.DelegatingSubject.RUN_AS_PRINCIPALS_SESSION_KEY >> is failing. >> >> Just some thoughts: Is shiro trying to clean the session from previous >> logins? > > No, there is no need that I can see - a new login will overwrite any > state in the session from a previous login. > >> Should this key be always present? > > The key is only set if performing runAs functionality. However, > during login or logout(), if a session exists, we attempt to remove it > to guarantee cleanup. > > >> Shouldn't shiro check if a Session is not invalidated before trying to >> remove that key? > > There isn't a Session.isValid() method at the moment. The reason is > that the HttpSession has no such method and people have been fine with > using that for over a decade. Also, if that method was present, I > fear that people would be calling isValid() _every_ time they wanted > to interact with a session, which might encourage an ugly programming > practice IMO. > > 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.
Les Hazlewood-2 wrote: > > > 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. Les Hazlewood-2 wrote: > > > It sounds as if you are using the servlet container sessions and not > Shiro's native sessions - is that correct? I'm fairly certain this > behavior does not happen with native sessions because calling > HttpSession.invalidate when using native sessions will null the > DelegatingSubject's internal session reference (so there wouldn't be > one at all to use in the clearRunAsIdentities() method). > > 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(). Les Hazlewood-2 wrote: > > > If you are using servlet container sessions, this would be a bug - > please open a Jira issue for it and we can get it in to the next > release. > > HTH! > > Best, > > -- > Les Hazlewood > Founder, Katasoft, Inc. > Application Security Products & Professional Apache Shiro Support and > Training: > http://www.katasoft.com > -- View this message in context: http://shiro-user.582556.n2.nabble.com/Problem-when-integrating-shiro-in-webapp-deployed-on-IBM-websphere-tp6377316p6380956.html Sent from the Shiro User mailing list archive at Nabble.com.
