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 user. > 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 <[email protected]> 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(StandardSession.java:1355) > > at > > org.apache.catalina.session.StandardSessionFacade.getAttribute(StandardSessionFacade.java:152) > > at > > org.apache.shiro.web.session.HttpServletSession.getAttribute(HttpServletSession.java:146) > > at > > org.apache.shiro.session.ProxiedSession.getAttribute(ProxiedSession.java:121) > > at > > org.apache.shiro.subject.support.DelegatingSubject.getRunAsPrincipalsStack(DelegatingSubject.java:469) > > at > > org.apache.shiro.subject.support.DelegatingSubject.getPrincipals(DelegatingSubject.java:153) > > at > > org.apache.shiro.subject.support.DelegatingSubject.isRemembered(DelegatingSubject.java:297) > > at > > com.lso.proxy.AuthenticatingProxyServlet.service(AuthenticatingProxyServlet.java:65) > > [...] > > > > 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: https://issues.jboss.org/browse/WELD-1813. 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: > > http://shiro-user.582556.n2.nabble.com/How-to-force-a-remembered-user-to-be-forgotten-td7579089.html. > > 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 > > > >
