Hi jim, I had the same thread state issue security utils get subject was not getting the correct subject every time. I was using tomee with http nio. I was trying to resolve the subject using session ID but I was getting different subjects randomly unrelated to session ID you can check the below URLhttps://issues.apache.org/jira/browse/SHIRO-613
The only way I could fix was using a subject builder and passing the session ID to the same and resolve the subject. Looks to me this might resolve your issue as well. Let me know if it works. Thanks,Sreenivas. On Thu, Feb 22, 2018 at 2:34 AM, jim.pier...@gmail.com<jim.pier...@gmail.com> wrote: Got a problem I cannot chase down, and need help. Hoping Les or Brian can set me straight. I have a web application configured using Shiro 1.4.0 with Form Authentication. I have a custom Realm to get Auth info from DB. I am using native Tomcat session management. We have a Tomcat cluster, i.e. 2 or 3, tomcat nodes configured to use SimpleTCPCluster to allow session replication across the tomcat nodes, per basic Tomcat Clustering setup. We front this with Apache mod_proxy for load balancing, but this problem presents even when hitting Tomcat1 node directly. If I only have one Tomcat node running, everything works perfectly. Users can login on first attempt with no issues. When I have a second, virtually identical, Tomcat node started, things get strange. To the layman, the first login attempt always fails, but the second attempt will always work. What I see in reality is the first attempt initially works, but then once authentication is successful, then next request triggers another 302 back to the login page. This is very consistent. I have chased and chased via debugger, but cannot seem to put my finger on it. I believe the issue is coming from the SecurityUtils.getSubject() code. I am not sure why, but it seems like I am not getting the Authenticated Subject back all the time. Its like the ThreadState does not have the right Subject attached to it. Its a long shot, but just looking for a clue on what might be happening. Here is my shiro.ini # ============================================================================= # Shiro INI configuration # # ============================================================================= #----------- # Main # ---------- [main] authc = my.auth.VerboseFormAuthenticationFilter authc.failureKeyAttribute=simpleShiroApplicationLoginFailure authc.loginUrl = /pre-auth/authentication/login.html authc.successUrl = /index.html logout.redirectUrl = /pre-auth/authentication/login.html vRealm = my.auth.VnfMgrCustomRealm securityManager.realms = $vnfmgrRealm credentialsMatcher = org.apache.shiro.authc.credential.Sha256CredentialsMatcher credentialsMatcher.storedCredentialsHexEncoded = false credentialsMatcher.hashIterations = 1024 vnfmgrRealm.credentialsMatcher = $credentialsMatcher # ----------------------------------------------------------------------------- # URLS - followed by Filter Chains. # ----------------------------------------------------------------------------- [urls] /v1/abc/** = anon /v1/gnfs/** = anon /logout = logout /pre-auth/welcome/** = anon /pre-auth/authentication/img/favicon/favicon.ico = anon /pre-auth/authentication/ajax/** = anon /pre-auth/authentication/css/** = anon /pre-auth/authentication/data/** = anon /pre-auth/authentication/design-resources/** = anon /pre-auth/authentication/fonts/** = anon /pre-auth/authentication/img/** = anon /pre-auth/authentication/js/** = anon /pre-auth/authentication/php/** = anon /pre-auth/authentication/sound/** = anon /pre-auth/authentication/xml/** = anon /v1/vim/heartbeat/heartbeat/** = anon /v1/vim/heartbeat/register/** = anon /** = authc Any suggestions on a better way to track this down would be appreciated. -- Sent from: http://shiro-user.582556.n2.nabble.com/
