shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lenny Primak <>
Subject Re: How to programmatically forget remembered Subject in the presence of parallel request threads?
Date Wed, 14 Oct 2015 12:32:25 GMT
No, the account can be deleted, just that “in memory” permissions can be cleaned out, so
you don’t have any issues
with stale sessions, etc.

> On Oct 14, 2015, at 7:13 AM, Joachim Kanbach <> wrote:
> Hi Lenny,
> thanks for your reply. You mean you don't actually delete the user account, but just
clear out all permissions from it (maybe by assigning a special role)? So the user accounts
exist forever?
>> I had the same requirement, and satisfied it by clearing out permissions for the
>> The user was still able to log in, but couldn’t do anything with the web site because
they had no permissions.
>> I called onLogout() for all outstanding realms after clearing out permissions in
the DB and that was that.
>>> On Oct 13, 2015, at 7:53 AM, Joachim Kanbach <> wrote:
>>> Hello all,
>>> I'm using Shiro on a proxy servlet that relays requests to another web module
containing REST web services, provided the user is authenticated *or* remembered, i.e. I currently
treat those two states the same. This works all nicely, but I'm having some trouble dealing
with the situation when an existing user gets deleted.
>>> As I see it, the Shiro "user" filter (as defined in my shiro.ini) still creates
a valid Subject using the supplied rememberMe cookie. My code that checks the validity of
the Subject therefore still executes the proxy request. It is in the web service module that
the actual check against the database takes place (also using Shiro), which then results in
a HTTP 401 response.
>>> My problem is that I can't find a clean way to programatically delete the rememberMe
cookie *and* the Session owned by the deleted Subject. In my proxy servlet, I can detect the
HTTP 401 response and perform a Subject.logout() in reaction to that, but then I run into
the problem that there are often multiple parallel requests running, which are created concurrently
by the frontend AngularJS single page app. So if I do a Subject.logout() on one of those threads,
the other threads can run into exceptions when doing a check like Subject.isAuthenticated()
or Subject.isRemembered(), as those are ultimately delegated to the underlying HttpSession.
The stack trace looks like this:
>>> java.lang.IllegalStateException: getAttribute: Session already invalidated
>>> 	at org.apache.catalina.session.StandardSession.getAttribute(
>>> 	at org.apache.catalina.session.StandardSessionFacade.getAttribute(
>>> 	at org.apache.shiro.web.session.HttpServletSession.getAttribute(
>>> 	at org.apache.shiro.session.ProxiedSession.getAttribute(
>>> 	at
>>> 	at
>>> 	at
>>> 	at com.lso.proxy.AuthenticatingProxyServlet.service(
>>>       [...]
>>> Issuing another Subject.logout() therefore also results in an exception.
>>> While I can catch and swallow all those exceptions, there's another log entry
that's ugly to say the least, which looks like this:
>>> WARN: WELD-000712: Unable to dissociate context org.jboss.weld.context.http.LazyHttpConversationContextImpl@307f4035
when destroying request org.apache.catalina.connector.RequestFacade@72507072
>>> I'm using GlassFish 4.1 and I believe the explanation for this warning can be
found here: As I don't use CDI in this web module
*yet*, it seems I would not be affected from the mentioned thread corruption even though GlassFish
4.1 ships with an affected version of Weld, but it would still be nicer to get rid of that
warning altogether.
>>> Does someone know a more elegant, straight-forward way to deal with this?
>>> I've found a thread about programmatic forgetting of a remembered user here:
But the problem I see with the proposed solution of calling RememberMeManager.forgetIdentity()
is that the Session doesn't get invalidated at the same time. So the AngularJS app will keep
sending the JSESSIONID cookie and the Subject will still be "authenticated", if they had logged
in to the same Session before the user got deleted. Therefore I believe I really have to invalidate
the Session at the same time.
>>> Best regards,
>>> Joachim Kanbach

View raw message