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.

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.

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).

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

Reply via email to