You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by "jim.piersol@gmail.com" <ji...@gmail.com> on 2018/02/21 21:04:27 UTC
Shiro using Tomcat Session Management with Tomcat Clustering
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/
Re: Shiro using Tomcat Session Management with Tomcat Clustering
Posted by Brian Demers <br...@gmail.com>.
Are you sure the tomcat session clustering is working? You may want to test that out independently.
-Brian
> On Feb 21, 2018, at 4:04 PM, "jim.piersol@gmail.com" <ji...@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/
Re: Shiro using Tomcat Session Management with Tomcat Clustering
Posted by sreenivas harshith <sr...@yahoo.com>.
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.piersol@gmail.com<ji...@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/