You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Andy Tripp <An...@vonage.com> on 2009/09/01 17:58:16 UTC
RE: need help plugging in my own session cache
I made some progress on this issue.
I added tracing to AuthorizingRealm.setAuthorizationCache(). I see that
it's first being correctly called to set the cache to my "custom"
VonageDistributedSessionCache that I specified in my ShiroFilter. But
then, I see that it's being called a second time, and getting *reset* to
some instance of SoftHashMapCache.
The stack trace of that 2nd call is below. So the issue is "where in
that stack trace is some code having the audacity to do something that
results in a call to AuthorizingRealm.setAuthorizationCache(), which
replaces the user-specified cache with the default of a
SoftHashMapCache?
My (uneducated) guess is that the culprit is the createSecurityManager()
call in IniConfiguration.processIni(). Why would we want to create a
security manager when in the middle of processing configuration data?
In any case, I think the use case is simple: trying to specify your own
CacheManager doesn't work. Here's my ShiroFilter:
# pull in vonage centralized authentication:
realmA = com.vonage.auth.VonageAuthenticationRealm
securityManager =
org.apache.shiro.web.DefaultWebSecurityManager
sessionManager =
org.apache.shiro.web.session.DefaultWebSessionManager
securityManager.sessionManager = $sessionManager
securityManager.sessionMode = native
#cacheManager =
org.apache.shiro.cache.DefaultCacheManager
cacheManager =
com.vonage.auth.VonageDistributedSessionCacheManager
securityManager.cacheManager = $cacheManager
sessionDAO =
org.apache.shiro.session.mgt.eis.MemorySessionDAO
#sessionDAO.cacheManager = $cacheManager
securityManager.sessionDAO = $sessionDAO
securityManager.realm = $realmA
And here's the stack trace I talked about:
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1206)
at
org.apache.shiro.realm.AuthorizingRealm.setAuthorizationCache(Authorizin
gRealm.java:109)
at
org.apache.shiro.realm.AuthorizingRealm.initAuthorizationCache(Authorizi
ngRealm.java:199)
at
org.apache.shiro.realm.AuthorizingRealm.afterCacheManagerSet(Authorizing
Realm.java:166)
at
org.apache.shiro.realm.CachingRealm.setCacheManager(CachingRealm.java:73
)
at
org.apache.shiro.mgt.RealmSecurityManager.applyCacheManagerToRealms(Real
mSecurityManager.java:116)
at
org.apache.shiro.mgt.RealmSecurityManager.afterRealmsSet(RealmSecurityMa
nager.java:86)
at
org.apache.shiro.mgt.AuthenticatingSecurityManager.afterRealmsSet(Authen
ticatingSecurityManager.java:178)
at
org.apache.shiro.mgt.AuthorizingSecurityManager.afterRealmsSet(Authorizi
ngSecurityManager.java:129)
at
org.apache.shiro.mgt.RealmSecurityManager.setRealms(RealmSecurityManager
.java:82)
at
org.apache.shiro.config.IniConfiguration.createSecurityManagerForSection
(IniConfiguration.java:242)
at
org.apache.shiro.config.IniConfiguration.createSecurityManager(IniConfig
uration.java:188)
at
org.apache.shiro.config.IniConfiguration.processIni(IniConfiguration.jav
a:172)
at
org.apache.shiro.config.IniConfiguration.process(IniConfiguration.java:1
61)
at
org.apache.shiro.config.IniConfiguration.load(IniConfiguration.java:127)
at
org.apache.shiro.config.TextConfiguration.loadTextConfig(TextConfigurati
on.java:70)
at
org.apache.shiro.config.TextConfiguration.init(TextConfiguration.java:86
)
at
org.apache.shiro.config.IniConfiguration.init(IniConfiguration.java:114)
at
org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:47)
at
org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:41)
at
org.apache.shiro.web.servlet.ShiroFilter.configure(ShiroFilter.java:322)
at
org.apache.shiro.web.servlet.ShiroFilter.onFilterConfigSet(ShiroFilter.j
ava:269)
at
org.apache.shiro.web.servlet.OncePerRequestFilter.init(OncePerRequestFil
ter.java:140)
at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFi
lterConfig.java:221)
at
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(Applicatio
nFilterConfig.java:302)
at
org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilte
rConfig.java:78)
at
org.apache.catalina.core.StandardContext.filterStart(StandardContext.jav
a:3635)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4222
)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.ja
va:760)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:9
27)
at
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java
:890)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:31
1)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSu
pport.java:120)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:448)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
Andy
________________________________
From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
Sent: Monday, August 31, 2009 10:25 AM
To: shiro-user@incubator.apache.org
Subject: RE: need help plugging in my own session cache
I need to get this working, and I'm happy to track it down myself, but I
need some starting direction.
If I want to use my own cache for storing session data, I know I should
write my own CacheManager and a class that implements Cache. But which
class do I tell to use my own cache? Is it SessionDAO, securityManager,
or my own Realm (in my case a subclass of JDBCRealm)? All three have a
cacheManager property.
Thanks,
Andy
________________________________
From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
Sent: Friday, August 28, 2009 2:56 PM
To: shiro-user@incubator.apache.org
Subject: need help plugging in my own session cache
Hi again,
I'm having trouble with specifying my own Cache.
I've specified my own CacheManager and Cache classes in my ShiroFilter:
realmA = com.vonage.auth.VonageAuthenticationRealm
securityManager =
org.apache.shiro.web.DefaultWebSecurityManager
sessionManager =
org.apache.shiro.web.session.DefaultWebSessionManager
securityManager.sessionManager = $sessionManager
securityManager.sessionMode = native
#cacheManager =
org.apache.shiro.cache.DefaultCacheManager
cacheManager =
com.vonage.auth.VonageDistributedSessionCacheManager
sessionDAO =
org.apache.shiro.session.mgt.eis.MemorySessionDAO
sessionDAO.cacheManager = $cacheManager
securityManager.sessionDAO = $sessionDAO
securityManager.cacheManager = $cacheManager
securityManager.realm = $realmA
realmA.cacheManager = $cacheManager
My VonageDistributedSessionCacheManager class simply returns an instance
of my VonageDistributedSessionCache class, which implements the Cache
interface.
The problem is that the various methods in my
VonageDistributedSessionCache class (get(), put(), etc) are never being
called. By adding tracing, I can confirm that my
VonageDistributedSessionCache constructor is being called from
AuthorizationRealm.initAuthorizationCache(). But when I login to my
servlet, my get() and put() methods are never called. On my first login
attempt to get to my servlet, I have no session and so I'm challenged
for username/password. Then on a second attempt, it lets me through. So
somewhere Shiro is caching my sessionid, but I don't know where. All I
know is that it's not using the Cache that I told it to :) In fact, I
told it 3 times ($cacheManager is mentioned 3 times above)!
So where is it in Shiro that checks the session cache? I see that
AuthorizingRealm.initAuthorizationCache() does create an instance of my
VonageDistributedSessionCache class, and calls setAuthorizationCache()
to store it. But I don't see any calls to the corresponding
getAuthorizationCache() to actually use it.
I'm not sure if this helps or not, but below is a stack trace from my
servlet. Somewhere along this chain of calls, somebody should have
called AuthorizingRealm.getAuthorizationCache() but didn't.
Thanks,
Andy
------------------------------------------------------------------------
----------------------
at java.lang.Thread.dumpStack(Thread.java:1206)
at
com.vonage.authenticatorTest.TestServlet1.doGet(TestServlet1.java:15)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:188)
at
org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterCh
ain.java:58)
at
org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java
:107)
at
org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.
java:137)
at
org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerReques
tFilter.java:190)
at
org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterCh
ain.java:63)
at
org.apache.shiro.web.servlet.ShiroFilter.executeChain(ShiroFilter.java:6
48)
at
org.apache.shiro.web.servlet.ShiroFilter.doFilterInternal(ShiroFilter.ja
va:588)
at
org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerReques
tFilter.java:190)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:172)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
74)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:87
5)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proc
essConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint
.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow
erWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:689)
at java.lang.Thread.run(Thread.java:619)
Re: need help plugging in my own session cache
Posted by Les Hazlewood <lh...@apache.org>.
Hi Andy,
I just committed the fix for this. I'm going to create a Test case in
a little bit to ensure this won't happen again.
Thanks for the notice!
Cheers,
Les
On Thu, Sep 17, 2009 at 11:27 AM, Les Hazlewood <lh...@apache.org> wrote:
> I think I might know what this is - I changed something temporarily
> when trying to debug your previous CacheManager issue and I probably
> have to change it back. I'll update when its fixed - sorry!
>
> Cheers,
>
> Les
>
> On Thu, Sep 17, 2009 at 11:24 AM, Andy Tripp <An...@vonage.com> wrote:
>> Hi,
>>
>> I'm having a problem with the "samples/web" sample. When I run it with
>> the latest shiro code, go to the main page
>> (http://localhost:8080/samples-web-1.0-incubating-SNAPSHOT/) and click
>> on "account page", I go directly to the account page. The point of the
>> demo is to show that you get redirected to a login page if you're not
>> logged in, so it seems to be broken. I've cleared my browser cookies.
>>
>> The same sample works fine from a previous version of shiro which I
>> downloaded on Aug 18.
>>
>> If I use the current shiro download, but overwrite the
>> shiro-web-1.0-incubating-SNAPSHOT.jar with the "August 18th" version, it
>> works correctly.
>> Could something have changed to break this?
>>
>> Andy
>>
>
Re: need help plugging in my own session cache
Posted by Les Hazlewood <lh...@apache.org>.
I think I might know what this is - I changed something temporarily
when trying to debug your previous CacheManager issue and I probably
have to change it back. I'll update when its fixed - sorry!
Cheers,
Les
On Thu, Sep 17, 2009 at 11:24 AM, Andy Tripp <An...@vonage.com> wrote:
> Hi,
>
> I'm having a problem with the "samples/web" sample. When I run it with
> the latest shiro code, go to the main page
> (http://localhost:8080/samples-web-1.0-incubating-SNAPSHOT/) and click
> on "account page", I go directly to the account page. The point of the
> demo is to show that you get redirected to a login page if you're not
> logged in, so it seems to be broken. I've cleared my browser cookies.
>
> The same sample works fine from a previous version of shiro which I
> downloaded on Aug 18.
>
> If I use the current shiro download, but overwrite the
> shiro-web-1.0-incubating-SNAPSHOT.jar with the "August 18th" version, it
> works correctly.
> Could something have changed to break this?
>
> Andy
>
RE: need help plugging in my own session cache
Posted by Andy Tripp <An...@vonage.com>.
Hi,
I'm having a problem with the "samples/web" sample. When I run it with
the latest shiro code, go to the main page
(http://localhost:8080/samples-web-1.0-incubating-SNAPSHOT/) and click
on "account page", I go directly to the account page. The point of the
demo is to show that you get redirected to a login page if you're not
logged in, so it seems to be broken. I've cleared my browser cookies.
The same sample works fine from a previous version of shiro which I
downloaded on Aug 18.
If I use the current shiro download, but overwrite the
shiro-web-1.0-incubating-SNAPSHOT.jar with the "August 18th" version, it
works correctly.
Could something have changed to break this?
Andy
Re: need help plugging in my own session cache
Posted by Les Hazlewood <lh...@apache.org>.
Please keep us posted and let us know how it goes.
Regards,
Les
On Tue, Sep 15, 2009 at 10:53 AM, Andy Tripp <An...@vonage.com> wrote:
> Thanks, Les, I'll take it from here.
> Andy
>
>> -----Original Message-----
>> From: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] On
>> Behalf Of Les Hazlewood
>> Sent: Tuesday, September 15, 2009 10:23 AM
>> To: shiro-user@incubator.apache.org
>> Subject: Re: need help plugging in my own session cache
>>
>> Hi Andrew,
>>
>> I've verified that the Cache is being called properly in the debugger
>> and that authorization data is being cached properly.
>>
>> Here is my test configuration (the trunk/samples/web web.xml, slightly
>> modified). Remember, the order in which the configuration elements
>> are defined matters - they translate to method calls, which internally
>> alter state. There is an ordering bug - see the config comments
>> below:
>>
>> <filter>
>> <filter-name>ShiroFilter</filter-name>
>> <filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-
>> class>
>> <init-param>
>> <param-name>config</param-name>
>> <param-value>
>> [main]
>> securityManager.sessionMode = native
>>
>> # Ordering bug - these 2 lines _must_ be defined before
>> # defining the CacheManager and setting it on the
>> securityManager (below):
>> sessionDAO =
>> org.apache.shiro.session.mgt.eis.MemorySessionDAO
>> securityManager.sessionDAO = $sessionDAO
>>
>> cacheManager = test.TestCacheManager
>> securityManager.cacheManager = $cacheManager
>>
>> demoRealm = org.apache.shiro.realm.text.PropertiesRealm
>> securityManager.realm = $demoRealm
>>
>> [filters]
>> authc.loginUrl = /login.jsp
>>
>> [urls]
>> # The /login.jsp is not restricted to authenticated
>> users (otherwise no one could log in!), but
>> # the 'authc' filter must still be specified for it so
>> it can process that url's
>> # login submissions. It is 'smart' enough to allow
>> those requests through as specified by the
>> # shiro.loginUrl above.
>> /login.jsp = authc
>>
>> /account/** = authc
>> /remoting/** = authc, roles[b2bClient],
>> perms["remote:invoke:lan,wan"]
>> </param-value>
>> </init-param>
>> </filter>
>>
>> And here is my test.TestCacheManager implementation:
>>
>> public class TestCacheManager implements CacheManager {
>>
>> Map<String, Cache> caches = new ConcurrentHashMap<String, Cache>();
>>
>> public Cache getCache(String name) throws CacheException {
>> if (name == null) {
>> throw new NullPointerException("name");
>> }
>>
>> Cache cache = caches.get(name);
>> if (cache == null) {
>> //MapCache with ConcurrentHashMap for testing only
>> //this would cause OutOfMemoryExceptions in a real app since
>> it
>> //would never proactively release instances. Use a
>> SoftHashMap in production
>> //environments, or better yet, a CacheManager
>> implementation supported
>> //by an enterprise Cache product (TerraCotta, Coherence,
>> GigaSpaces, etc).
>> cache = new MapCache(name, new ConcurrentHashMap());
>> caches.put(name, cache);
>> }
>>
>> return cache;
>> }
>> }
>>
>> Regards,
>>
>> Les
>>
>> On Tue, Sep 15, 2009 at 9:44 AM, Les Hazlewood <lh...@apache.org>
>> wrote:
>> > On Mon, Sep 14, 2009 at 4:15 PM, Andy Tripp <An...@vonage.com>
>> wrote:
>> >
>> >> Cache's get() and put() methods are never called, and I can try
>> tracking
>> >> down the problem, but I can't figure out what class should be making
>> >> these
>> >> calls.
>> >
>> > These would be done by the Realm instance, via the superclass
>> > AuthorizingRealm implementation - specifically in the
>> > 'getAuthorizationInfo' method. This method checks the cache, and if
>> > not found in the cache, then delegates to the 'doGetAuthorizationInfo'
>> > method which is implemented by subclasses.
>> >
>> > I hope that helps - I'll keep debugging from my end...
>> >
>
RE: need help plugging in my own session cache
Posted by Andy Tripp <An...@vonage.com>.
Thanks, Les, I'll take it from here.
Andy
> -----Original Message-----
> From: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] On
> Behalf Of Les Hazlewood
> Sent: Tuesday, September 15, 2009 10:23 AM
> To: shiro-user@incubator.apache.org
> Subject: Re: need help plugging in my own session cache
>
> Hi Andrew,
>
> I've verified that the Cache is being called properly in the debugger
> and that authorization data is being cached properly.
>
> Here is my test configuration (the trunk/samples/web web.xml, slightly
> modified). Remember, the order in which the configuration elements
> are defined matters - they translate to method calls, which internally
> alter state. There is an ordering bug - see the config comments
> below:
>
> <filter>
> <filter-name>ShiroFilter</filter-name>
> <filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-
> class>
> <init-param>
> <param-name>config</param-name>
> <param-value>
> [main]
> securityManager.sessionMode = native
>
> # Ordering bug - these 2 lines _must_ be defined before
> # defining the CacheManager and setting it on the
> securityManager (below):
> sessionDAO =
> org.apache.shiro.session.mgt.eis.MemorySessionDAO
> securityManager.sessionDAO = $sessionDAO
>
> cacheManager = test.TestCacheManager
> securityManager.cacheManager = $cacheManager
>
> demoRealm = org.apache.shiro.realm.text.PropertiesRealm
> securityManager.realm = $demoRealm
>
> [filters]
> authc.loginUrl = /login.jsp
>
> [urls]
> # The /login.jsp is not restricted to authenticated
> users (otherwise no one could log in!), but
> # the 'authc' filter must still be specified for it so
> it can process that url's
> # login submissions. It is 'smart' enough to allow
> those requests through as specified by the
> # shiro.loginUrl above.
> /login.jsp = authc
>
> /account/** = authc
> /remoting/** = authc, roles[b2bClient],
> perms["remote:invoke:lan,wan"]
> </param-value>
> </init-param>
> </filter>
>
> And here is my test.TestCacheManager implementation:
>
> public class TestCacheManager implements CacheManager {
>
> Map<String, Cache> caches = new ConcurrentHashMap<String, Cache>();
>
> public Cache getCache(String name) throws CacheException {
> if (name == null) {
> throw new NullPointerException("name");
> }
>
> Cache cache = caches.get(name);
> if (cache == null) {
> //MapCache with ConcurrentHashMap for testing only
> //this would cause OutOfMemoryExceptions in a real app since
> it
> //would never proactively release instances. Use a
> SoftHashMap in production
> //environments, or better yet, a CacheManager
> implementation supported
> //by an enterprise Cache product (TerraCotta, Coherence,
> GigaSpaces, etc).
> cache = new MapCache(name, new ConcurrentHashMap());
> caches.put(name, cache);
> }
>
> return cache;
> }
> }
>
> Regards,
>
> Les
>
> On Tue, Sep 15, 2009 at 9:44 AM, Les Hazlewood <lh...@apache.org>
> wrote:
> > On Mon, Sep 14, 2009 at 4:15 PM, Andy Tripp <An...@vonage.com>
> wrote:
> >
> >> Cache's get() and put() methods are never called, and I can try
> tracking
> >> down the problem, but I can't figure out what class should be making
> >> these
> >> calls.
> >
> > These would be done by the Realm instance, via the superclass
> > AuthorizingRealm implementation - specifically in the
> > 'getAuthorizationInfo' method. This method checks the cache, and if
> > not found in the cache, then delegates to the 'doGetAuthorizationInfo'
> > method which is implemented by subclasses.
> >
> > I hope that helps - I'll keep debugging from my end...
> >
Re: need help plugging in my own session cache
Posted by Les Hazlewood <lh...@apache.org>.
Hi Andrew,
I've verified that the Cache is being called properly in the debugger
and that authorization data is being cached properly.
Here is my test configuration (the trunk/samples/web web.xml, slightly
modified). Remember, the order in which the configuration elements
are defined matters - they translate to method calls, which internally
alter state. There is an ordering bug - see the config comments
below:
<filter>
<filter-name>ShiroFilter</filter-name>
<filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-class>
<init-param>
<param-name>config</param-name>
<param-value>
[main]
securityManager.sessionMode = native
# Ordering bug - these 2 lines _must_ be defined before
# defining the CacheManager and setting it on the
securityManager (below):
sessionDAO = org.apache.shiro.session.mgt.eis.MemorySessionDAO
securityManager.sessionDAO = $sessionDAO
cacheManager = test.TestCacheManager
securityManager.cacheManager = $cacheManager
demoRealm = org.apache.shiro.realm.text.PropertiesRealm
securityManager.realm = $demoRealm
[filters]
authc.loginUrl = /login.jsp
[urls]
# The /login.jsp is not restricted to authenticated
users (otherwise no one could log in!), but
# the 'authc' filter must still be specified for it so
it can process that url's
# login submissions. It is 'smart' enough to allow
those requests through as specified by the
# shiro.loginUrl above.
/login.jsp = authc
/account/** = authc
/remoting/** = authc, roles[b2bClient],
perms["remote:invoke:lan,wan"]
</param-value>
</init-param>
</filter>
And here is my test.TestCacheManager implementation:
public class TestCacheManager implements CacheManager {
Map<String, Cache> caches = new ConcurrentHashMap<String, Cache>();
public Cache getCache(String name) throws CacheException {
if (name == null) {
throw new NullPointerException("name");
}
Cache cache = caches.get(name);
if (cache == null) {
//MapCache with ConcurrentHashMap for testing only
//this would cause OutOfMemoryExceptions in a real app since it
//would never proactively release instances. Use a
SoftHashMap in production
//environments, or better yet, a CacheManager
implementation supported
//by an enterprise Cache product (TerraCotta, Coherence,
GigaSpaces, etc).
cache = new MapCache(name, new ConcurrentHashMap());
caches.put(name, cache);
}
return cache;
}
}
Regards,
Les
On Tue, Sep 15, 2009 at 9:44 AM, Les Hazlewood <lh...@apache.org> wrote:
> On Mon, Sep 14, 2009 at 4:15 PM, Andy Tripp <An...@vonage.com> wrote:
>
>> Cache's get() and put() methods are never called, and I can try tracking
>> down the problem, but I can't figure out what class should be making
>> these
>> calls.
>
> These would be done by the Realm instance, via the superclass
> AuthorizingRealm implementation - specifically in the
> 'getAuthorizationInfo' method. This method checks the cache, and if
> not found in the cache, then delegates to the 'doGetAuthorizationInfo'
> method which is implemented by subclasses.
>
> I hope that helps - I'll keep debugging from my end...
>
Re: need help plugging in my own session cache
Posted by Les Hazlewood <lh...@apache.org>.
Hi Andrew,
I'm trying to debug this issue now. I'm using a simple
'TestCacheManager' class I created that uses HashMaps to back its
caches and I'm no longer seeing the SoftHashMapCache instances created
(as expected).
I've got a debugger set up and I'm now trying to see if/when the cache
put/get methods would be called. I'll let you know.
- Les
On Mon, Sep 14, 2009 at 4:49 PM, Les Hazlewood <lh...@apache.org> wrote:
> Oops - I had meant to answer this Friday but I forgot. My apologies.
>
> I'm connecting a debugger to some test cases to find out why the
> SoftHashMapCache might be overwriting your cache. I'll report back
> what I find hopefully soon.
>
> - Les
>
> On Mon, Sep 14, 2009 at 4:15 PM, Andy Tripp <An...@vonage.com> wrote:
>> Les,
>>
>> I still need some help on this - just some general guidance on where it
>> is that's supposed to be using the Cache to check for session data. My
>> custom
>> Cache's get() and put() methods are never called, and I can try tracking
>> down the problem, but I can't figure out what class should be making
>> these
>> calls.
>>
>> Thanks,
>> Andy
>>
>>> -----Original Message-----
>>> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
>>> Sent: Tuesday, September 08, 2009 12:02 PM
>>> To: shiro-user@incubator.apache.org
>>> Subject: RE: need help plugging in my own session cache
>>>
>>> Les,
>>>
>>> To workaround the ShiroFilter config problem, I've just overridden
>>> getAuthorizationCache() in my subclass of JdbcRealm. But I still see
>> no
>>> calls to any of the Cache methods.
>>>
>>> I need some help on understanding the "big picture" here. What class
>>> calls the Cache methods to see if the user has a session? I can't seem
>>> to track down any such calls.I tried overriding getAuthorizationInfo()
>>> in my JdbcRealm subclass, but that's never called. I've put tracing in
>>> the default SoftHashMapCache.get() method, and it's never called
>> either.
>>>
>>> Thanks,
>>> Andy
>>
>
Re: need help plugging in my own session cache
Posted by Les Hazlewood <lh...@apache.org>.
On Mon, Sep 14, 2009 at 4:15 PM, Andy Tripp <An...@vonage.com> wrote:
> Cache's get() and put() methods are never called, and I can try tracking
> down the problem, but I can't figure out what class should be making
> these
> calls.
These would be done by the Realm instance, via the superclass
AuthorizingRealm implementation - specifically in the
'getAuthorizationInfo' method. This method checks the cache, and if
not found in the cache, then delegates to the 'doGetAuthorizationInfo'
method which is implemented by subclasses.
I hope that helps - I'll keep debugging from my end...
Re: need help plugging in my own session cache
Posted by Les Hazlewood <lh...@apache.org>.
Oops - I had meant to answer this Friday but I forgot. My apologies.
I'm connecting a debugger to some test cases to find out why the
SoftHashMapCache might be overwriting your cache. I'll report back
what I find hopefully soon.
- Les
On Mon, Sep 14, 2009 at 4:15 PM, Andy Tripp <An...@vonage.com> wrote:
> Les,
>
> I still need some help on this - just some general guidance on where it
> is that's supposed to be using the Cache to check for session data. My
> custom
> Cache's get() and put() methods are never called, and I can try tracking
> down the problem, but I can't figure out what class should be making
> these
> calls.
>
> Thanks,
> Andy
>
>> -----Original Message-----
>> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
>> Sent: Tuesday, September 08, 2009 12:02 PM
>> To: shiro-user@incubator.apache.org
>> Subject: RE: need help plugging in my own session cache
>>
>> Les,
>>
>> To workaround the ShiroFilter config problem, I've just overridden
>> getAuthorizationCache() in my subclass of JdbcRealm. But I still see
> no
>> calls to any of the Cache methods.
>>
>> I need some help on understanding the "big picture" here. What class
>> calls the Cache methods to see if the user has a session? I can't seem
>> to track down any such calls.I tried overriding getAuthorizationInfo()
>> in my JdbcRealm subclass, but that's never called. I've put tracing in
>> the default SoftHashMapCache.get() method, and it's never called
> either.
>>
>> Thanks,
>> Andy
>
RE: need help plugging in my own session cache
Posted by Andy Tripp <An...@vonage.com>.
Les,
I still need some help on this - just some general guidance on where it
is that's supposed to be using the Cache to check for session data. My
custom
Cache's get() and put() methods are never called, and I can try tracking
down the problem, but I can't figure out what class should be making
these
calls.
Thanks,
Andy
> -----Original Message-----
> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
> Sent: Tuesday, September 08, 2009 12:02 PM
> To: shiro-user@incubator.apache.org
> Subject: RE: need help plugging in my own session cache
>
> Les,
>
> To workaround the ShiroFilter config problem, I've just overridden
> getAuthorizationCache() in my subclass of JdbcRealm. But I still see
no
> calls to any of the Cache methods.
>
> I need some help on understanding the "big picture" here. What class
> calls the Cache methods to see if the user has a session? I can't seem
> to track down any such calls.I tried overriding getAuthorizationInfo()
> in my JdbcRealm subclass, but that's never called. I've put tracing in
> the default SoftHashMapCache.get() method, and it's never called
either.
>
> Thanks,
> Andy
RE: need help plugging in my own session cache
Posted by Andy Tripp <An...@vonage.com>.
Les,
To workaround the ShiroFilter config problem, I've just overridden
getAuthorizationCache() in my subclass of JdbcRealm. But I still see no
calls to any of the Cache methods.
I need some help on understanding the "big picture" here. What class
calls the Cache methods to see if the user has a session? I can't seem
to track down any such calls.I tried overriding getAuthorizationInfo()
in my JdbcRealm subclass, but that's never called. I've put tracing in
the default SoftHashMapCache.get() method, and it's never called either.
Thanks,
Andy
RE: need help plugging in my own session cache
Posted by Andy Tripp <An...@vonage.com>.
I finally got around to testing this workaround, and it didn't work.
Here's what I'm using:
# pull in vonage centralized authentication:
realmA = com.vonage.auth.VonageAuthenticationRealm
securityManager = org.apache.shiro.web.DefaultWebSecurityManager
sessionManager = org.apache.shiro.web.session.DefaultWebSessionManager
securityManager.sessionManager = $sessionManager
securityManager.sessionMode = native
#cacheManager = org.apache.shiro.cache.DefaultCacheManager
sessionDAO = org.apache.shiro.session.mgt.eis.MemorySessionDAO
securityManager.sessionDAO = $sessionDAO
securityManager.realm = $realmA
cacheManager = com.vonage.auth.VonageDistributedSessionCacheManager
securityManager.cacheManager = $cacheManager
sessionDAO.cacheManager = $cacheManager
realmA.cacheManager = $cacheManager
I'm seeing 4 calls to AuthorizingRealm.setAuthorizationCache(). First, it's passed a SoftHashMapCache, then twice it's called with my VonageDistributedSessionCache, and then one final call with a SoftHashMapCache again.
Oddly, I noticed that every time AuthorizingRealm.setAuthorizationCache() is called, the current this.authorizationCache is null. It's getting nulled out
by calls to afterCacheManagerSet().
Andy
> -----Original Message-----
> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
> Sent: Thursday, September 03, 2009 3:43 PM
> To: shiro-user@incubator.apache.org
> Subject: RE: need help plugging in my own session cache
>
> I created a Jira issue: https://issues.apache.org/jira/browse/SHIRO-95
>
> I'll try this workaround now.
> Thanks, Les!
>
> Andy
>
> > -----Original Message-----
> > From: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] On
> > Behalf Of Les Hazlewood
> > Sent: Wednesday, September 02, 2009 3:03 PM
> > To: shiro-user@incubator.apache.org
> > Subject: Re: need help plugging in my own session cache
> >
> > This is an order of operations bug. Please open a Jira issue so we
> > can fix it.
> >
> > In the mean time, setting the sessionDAO on the securityManager
> > _before_ setting the cache manager should do the trick.
> >
> > Here is a configuration that is working for me:
> >
> > <filter>
> > <filter-name>ShiroFilter</filter-name>
> > <filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-
> > class>
> > <init-param>
> > <param-name>config</param-name>
> > <param-value>
> > [main]
> >
> > securityManager.sessionMode = native
> >
> > sessionDAO =
> > org.apache.shiro.session.mgt.eis.MemorySessionDAO
> > securityManager.sessionDAO = $sessionDAO
> >
> > cacheManager = TestCacheManager
> > securityManager.cacheManager = $cacheManager
> >
> > demoRealm = org.apache.shiro.realm.text.PropertiesRealm
> > securityManager.realm = $demoRealm
> >
> > # add [filters] and [urls] sections here as necessary
> >
> > </param-value>
> > </init-param>
> > </filter>
> >
> > On Wed, Sep 2, 2009 at 1:16 PM, Les Hazlewood<lh...@apache.org>
> > wrote:
> > > Hi Andy,
> > >
> > > There is definitely a bug in the configuration stuff - I'm looking in
> > > to it to find out what may be wrong. I'll keep you posted.
> > >
> > > - Les
> > >
> > > On Tue, Sep 1, 2009 at 2:39 PM, Les Hazlewood<lh...@apache.org>
> > wrote:
> > >> Hi Andy,
> > >>
> > >> I'll have to give this a look sometime later tonight or tomorrow when
> > >> I have time - I'm kinda slammed today. But don't worry - we'll get
> it
> > >> working!
> > >>
> > >> Best,
> > >>
> > >> Les
> > >>
> > >> On Tue, Sep 1, 2009 at 11:58 AM, Andy Tripp<An...@vonage.com>
> > wrote:
> > >>> I made some progress on this issue.
> > >>>
> > >>>
> > >>>
> > >>> I added tracing to AuthorizingRealm.setAuthorizationCache(). I see
> > that it's
> > >>> first being correctly called to set the cache to my "custom"
> > >>> VonageDistributedSessionCache that I specified in my ShiroFilter.
> But
> > then,
> > >>> I see that it's being called a second time, and getting *reset* to
> > some
> > >>> instance of SoftHashMapCache.
> > >>>
> > >>>
> > >>>
> > >>> The stack trace of that 2nd call is below. So the issue is "where in
> > that
> > >>> stack trace is some code having the audacity to do something that
> > results in
> > >>> a call to AuthorizingRealm.setAuthorizationCache(), which replaces
> the
> > >>> user-specified cache with the default of a SoftHashMapCache?
> > >>>
> > >>>
> > >>>
> > >>> My (uneducated) guess is that the culprit is the
> > createSecurityManager()
> > >>> call in IniConfiguration.processIni(). Why would we want to create a
> > >>> security manager when in the middle of processing configuration
> data?
> > >>>
> > >>>
> > >>>
> > >>> In any case, I think the use case is simple: trying to specify your
> > own
> > >>> CacheManager doesn't work. Here's my ShiroFilter:
> > >>>
> > >>> # pull in vonage centralized authentication:
> > >>>
> > >>> realmA = com.vonage.auth.VonageAuthenticationRealm
> > >>>
> > >>> securityManager =
> > >>> org.apache.shiro.web.DefaultWebSecurityManager
> > >>>
> > >>> sessionManager =
> > >>> org.apache.shiro.web.session.DefaultWebSessionManager
> > >>>
> > >>> securityManager.sessionManager = $sessionManager
> > >>>
> > >>> securityManager.sessionMode = native
> > >>>
> > >>> #cacheManager =
> > org.apache.shiro.cache.DefaultCacheManager
> > >>>
> > >>>
> > >>>
> > >>> cacheManager =
> > >>> com.vonage.auth.VonageDistributedSessionCacheManager
> > >>>
> > >>> securityManager.cacheManager = $cacheManager
> > >>>
> > >>>
> > >>>
> > >>> sessionDAO =
> > >>> org.apache.shiro.session.mgt.eis.MemorySessionDAO
> > >>>
> > >>> #sessionDAO.cacheManager = $cacheManager
> > >>>
> > >>> securityManager.sessionDAO = $sessionDAO
> > >>>
> > >>> securityManager.realm = $realmA
> > >>>
> > >>>
> > >>>
> > >>> And here's the stack trace I talked about:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> java.lang.Exception: Stack trace
> > >>>
> > >>> at java.lang.Thread.dumpStack(Thread.java:1206)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.realm.AuthorizingRealm.setAuthorizationCache(AuthorizingR
> > ealm.java:109)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.realm.AuthorizingRealm.initAuthorizationCache(Authorizing
> > Realm.java:199)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.realm.AuthorizingRealm.afterCacheManagerSet(AuthorizingRe
> > alm.java:166)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.realm.CachingRealm.setCacheManager(CachingRealm.java:73)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.mgt.RealmSecurityManager.applyCacheManagerToRealms(RealmS
> > ecurityManager.java:116)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.mgt.RealmSecurityManager.afterRealmsSet(RealmSecurityMana
> > ger.java:86)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.mgt.AuthenticatingSecurityManager.afterRealmsSet(Authenti
> > catingSecurityManager.java:178)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.mgt.AuthorizingSecurityManager.afterRealmsSet(Authorizing
> > SecurityManager.java:129)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.mgt.RealmSecurityManager.setRealms(RealmSecurityManager.j
> > ava:82)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.config.IniConfiguration.createSecurityManagerForSection(I
> > niConfiguration.java:242)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.config.IniConfiguration.createSecurityManager(IniConfigur
> > ation.java:188)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.config.IniConfiguration.processIni(IniConfiguration.java:
> > 172)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.config.IniConfiguration.process(IniConfiguration.java:161
> > )
> > >>>
> > >>> at
> > >>>
> > org.apache.shiro.config.IniConfiguration.load(IniConfiguration.java:127)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.config.TextConfiguration.loadTextConfig(TextConfiguration
> > .java:70)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.config.TextConfiguration.init(TextConfiguration.java:86)
> > >>>
> > >>> at
> > >>>
> > org.apache.shiro.config.IniConfiguration.init(IniConfiguration.java:114)
> > >>>
> > >>> at
> > org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:47)
> > >>>
> > >>> at
> > org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:41)
> > >>>
> > >>> at
> > >>>
> > org.apache.shiro.web.servlet.ShiroFilter.configure(ShiroFilter.java:322)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.web.servlet.ShiroFilter.onFilterConfigSet(ShiroFilter.jav
> > a:269)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.web.servlet.OncePerRequestFilter.init(OncePerRequestFilte
> > r.java:140)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilt
> > erConfig.java:221)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationF
> > ilterConfig.java:302)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterC
> > onfig.java:78)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:
> > 3635)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4222)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java
> > :760)
> > >>>
> > >>> at
> > >>>
> > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
> > >>>
> > >>> at
> > >>>
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:927
> > )
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:8
> > 90)
> > >>>
> > >>> at
> > >>>
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
> > >>>
> > >>> at
> > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupp
> > ort.java:120)
> > >>>
> > >>> at
> > >>>
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
> > >>>
> > >>> at
> > org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
> > >>>
> > >>> at
> > >>>
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
> > >>>
> > >>> at
> > >>>
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
> > >>>
> > >>> at
> > >>>
> > org.apache.catalina.core.StandardService.start(StandardService.java:448)
> > >>>
> > >>> at
> > >>>
> org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
> > >>>
> > >>> at
> org.apache.catalina.startup.Catalina.start(Catalina.java:552)
> > >>>
> > >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >>>
> > >>> at
> > >>>
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> > 39)
> > >>>
> > >>> at
> > >>>
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
> > pl.java:25)
> > >>>
> > >>> at java.lang.reflect.Method.invoke(Method.java:597)
> > >>>
> > >>> at
> > org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
> > >>>
> > >>> at
> > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
> > >>>
> > >>>
> > >>>
> > >>> Andy
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> ________________________________
> > >>>
> > >>> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
> > >>> Sent: Monday, August 31, 2009 10:25 AM
> > >>> To: shiro-user@incubator.apache.org
> > >>> Subject: RE: need help plugging in my own session cache
> > >>>
> > >>>
> > >>>
> > >>> I need to get this working, and I'm happy to track it down myself,
> but
> > I
> > >>> need some starting direction.
> > >>>
> > >>>
> > >>>
> > >>> If I want to use my own cache for storing session data, I know I
> > should
> > >>> write my own CacheManager and a class that implements Cache. But
> which
> > class
> > >>> do I tell to use my own cache? Is it SessionDAO, securityManager, or
> > my own
> > >>> Realm (in my case a subclass of JDBCRealm)? All three have a
> > cacheManager
> > >>> property.
> > >>>
> > >>>
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Andy
> > >>>
> > >>>
> > >>>
> > >>> ________________________________
> > >>>
> > >>> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
> > >>> Sent: Friday, August 28, 2009 2:56 PM
> > >>> To: shiro-user@incubator.apache.org
> > >>> Subject: need help plugging in my own session cache
> > >>>
> > >>>
> > >>>
> > >>> Hi again,
> > >>>
> > >>>
> > >>>
> > >>> I'm having trouble with specifying my own Cache.
> > >>>
> > >>> I've specified my own CacheManager and Cache classes in my
> > ShiroFilter:
> > >>>
> > >>>
> > >>>
> > >>> realmA = com.vonage.auth.VonageAuthenticationRealm
> > >>>
> > >>> securityManager =
> > >>> org.apache.shiro.web.DefaultWebSecurityManager
> > >>>
> > >>> sessionManager =
> > >>> org.apache.shiro.web.session.DefaultWebSessionManager
> > >>>
> > >>> securityManager.sessionManager = $sessionManager
> > >>>
> > >>> securityManager.sessionMode = native
> > >>>
> > >>> #cacheManager =
> > org.apache.shiro.cache.DefaultCacheManager
> > >>>
> > >>> cacheManager =
> > >>> com.vonage.auth.VonageDistributedSessionCacheManager
> > >>>
> > >>> sessionDAO =
> > >>> org.apache.shiro.session.mgt.eis.MemorySessionDAO
> > >>>
> > >>> sessionDAO.cacheManager = $cacheManager
> > >>>
> > >>> securityManager.sessionDAO = $sessionDAO
> > >>>
> > >>> securityManager.cacheManager = $cacheManager
> > >>>
> > >>> securityManager.realm = $realmA
> > >>>
> > >>> realmA.cacheManager = $cacheManager
> > >>>
> > >>>
> > >>>
> > >>> My VonageDistributedSessionCacheManager class simply returns an
> > instance of
> > >>> my VonageDistributedSessionCache class, which implements the Cache
> > >>> interface.
> > >>>
> > >>>
> > >>>
> > >>> The problem is that the various methods in my
> > VonageDistributedSessionCache
> > >>> class (get(), put(), etc) are never being called. By adding tracing,
> I
> > can
> > >>> confirm that my VonageDistributedSessionCache constructor is being
> > called
> > >>> from AuthorizationRealm.initAuthorizationCache(). But when I login
> to
> > my
> > >>> servlet, my get() and put() methods are never called. On my first
> > login
> > >>> attempt to get to my servlet, I have no session and so I'm
> challenged
> > for
> > >>> username/password. Then on a second attempt, it lets me through. So
> > >>> somewhere Shiro is caching my sessionid, but I don't know where. All
> I
> > know
> > >>> is that it's not using the Cache that I told it to :) In fact, I
> told
> > it 3
> > >>> times ($cacheManager is mentioned 3 times above)!
> > >>>
> > >>>
> > >>>
> > >>> So where is it in Shiro that checks the session cache? I see that
> > >>> AuthorizingRealm.initAuthorizationCache() does create an instance of
> > my
> > >>> VonageDistributedSessionCache class, and calls
> setAuthorizationCache()
> > to
> > >>> store it. But I don't see any calls to the corresponding
> > >>> getAuthorizationCache() to actually use it.
> > >>>
> > >>>
> > >>>
> > >>> I'm not sure if this helps or not, but below is a stack trace from
> my
> > >>> servlet. Somewhere along this chain of calls, somebody should have
> > called
> > >>> AuthorizingRealm.getAuthorizationCache() but didn't.
> > >>>
> > >>>
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Andy
> > >>>
> > >>> --------------------------------------------------------------------
> --
> > ------------------------
> > >>>
> > >>> at java.lang.Thread.dumpStack(Thread.java:1206)
> > >>>
> > >>> at
> > >>>
> com.vonage.authenticatorTest.TestServlet1.doGet(TestServlet1.java:15)
> > >>>
> > >>> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
> > >>>
> > >>> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
> > onFilterChain.java:269)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
> > Chain.java:188)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChai
> > n.java:58)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:1
> > 07)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.ja
> > va:137)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestF
> > ilter.java:190)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChai
> > n.java:63)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.web.servlet.ShiroFilter.executeChain(ShiroFilter.java:648
> > )
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.web.servlet.ShiroFilter.doFilterInternal(ShiroFilter.java
> > :588)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestF
> > ilter.java:190)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
> > onFilterChain.java:215)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
> > Chain.java:188)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
> > java:213)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
> > java:172)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1
> > 27)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
> > 17)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja
> > va:108)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174
> > )
> > >>>
> > >>> at
> > >>>
> >
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proces
> > sConnection(Http11BaseProtocol.java:665)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.j
> > ava:528)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollower
> > WorkerThread.java:81)
> > >>>
> > >>> at
> > >>>
> >
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.j
> > ava:689)
> > >>>
> > >>> at java.lang.Thread.run(Thread.java:619)
> > >>>
> > >>>
> > >>
> > >
RE: need help plugging in my own session cache
Posted by Andy Tripp <An...@vonage.com>.
I created a Jira issue: https://issues.apache.org/jira/browse/SHIRO-95
I'll try this workaround now.
Thanks, Les!
Andy
> -----Original Message-----
> From: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] On
> Behalf Of Les Hazlewood
> Sent: Wednesday, September 02, 2009 3:03 PM
> To: shiro-user@incubator.apache.org
> Subject: Re: need help plugging in my own session cache
>
> This is an order of operations bug. Please open a Jira issue so we
> can fix it.
>
> In the mean time, setting the sessionDAO on the securityManager
> _before_ setting the cache manager should do the trick.
>
> Here is a configuration that is working for me:
>
> <filter>
> <filter-name>ShiroFilter</filter-name>
> <filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-
> class>
> <init-param>
> <param-name>config</param-name>
> <param-value>
> [main]
>
> securityManager.sessionMode = native
>
> sessionDAO =
> org.apache.shiro.session.mgt.eis.MemorySessionDAO
> securityManager.sessionDAO = $sessionDAO
>
> cacheManager = TestCacheManager
> securityManager.cacheManager = $cacheManager
>
> demoRealm = org.apache.shiro.realm.text.PropertiesRealm
> securityManager.realm = $demoRealm
>
> # add [filters] and [urls] sections here as necessary
>
> </param-value>
> </init-param>
> </filter>
>
> On Wed, Sep 2, 2009 at 1:16 PM, Les Hazlewood<lh...@apache.org>
> wrote:
> > Hi Andy,
> >
> > There is definitely a bug in the configuration stuff - I'm looking in
> > to it to find out what may be wrong. I'll keep you posted.
> >
> > - Les
> >
> > On Tue, Sep 1, 2009 at 2:39 PM, Les Hazlewood<lh...@apache.org>
> wrote:
> >> Hi Andy,
> >>
> >> I'll have to give this a look sometime later tonight or tomorrow when
> >> I have time - I'm kinda slammed today. But don't worry - we'll get it
> >> working!
> >>
> >> Best,
> >>
> >> Les
> >>
> >> On Tue, Sep 1, 2009 at 11:58 AM, Andy Tripp<An...@vonage.com>
> wrote:
> >>> I made some progress on this issue.
> >>>
> >>>
> >>>
> >>> I added tracing to AuthorizingRealm.setAuthorizationCache(). I see
> that it's
> >>> first being correctly called to set the cache to my "custom"
> >>> VonageDistributedSessionCache that I specified in my ShiroFilter. But
> then,
> >>> I see that it's being called a second time, and getting *reset* to
> some
> >>> instance of SoftHashMapCache.
> >>>
> >>>
> >>>
> >>> The stack trace of that 2nd call is below. So the issue is "where in
> that
> >>> stack trace is some code having the audacity to do something that
> results in
> >>> a call to AuthorizingRealm.setAuthorizationCache(), which replaces the
> >>> user-specified cache with the default of a SoftHashMapCache?
> >>>
> >>>
> >>>
> >>> My (uneducated) guess is that the culprit is the
> createSecurityManager()
> >>> call in IniConfiguration.processIni(). Why would we want to create a
> >>> security manager when in the middle of processing configuration data?
> >>>
> >>>
> >>>
> >>> In any case, I think the use case is simple: trying to specify your
> own
> >>> CacheManager doesn't work. Here's my ShiroFilter:
> >>>
> >>> # pull in vonage centralized authentication:
> >>>
> >>> realmA = com.vonage.auth.VonageAuthenticationRealm
> >>>
> >>> securityManager =
> >>> org.apache.shiro.web.DefaultWebSecurityManager
> >>>
> >>> sessionManager =
> >>> org.apache.shiro.web.session.DefaultWebSessionManager
> >>>
> >>> securityManager.sessionManager = $sessionManager
> >>>
> >>> securityManager.sessionMode = native
> >>>
> >>> #cacheManager =
> org.apache.shiro.cache.DefaultCacheManager
> >>>
> >>>
> >>>
> >>> cacheManager =
> >>> com.vonage.auth.VonageDistributedSessionCacheManager
> >>>
> >>> securityManager.cacheManager = $cacheManager
> >>>
> >>>
> >>>
> >>> sessionDAO =
> >>> org.apache.shiro.session.mgt.eis.MemorySessionDAO
> >>>
> >>> #sessionDAO.cacheManager = $cacheManager
> >>>
> >>> securityManager.sessionDAO = $sessionDAO
> >>>
> >>> securityManager.realm = $realmA
> >>>
> >>>
> >>>
> >>> And here's the stack trace I talked about:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> java.lang.Exception: Stack trace
> >>>
> >>> at java.lang.Thread.dumpStack(Thread.java:1206)
> >>>
> >>> at
> >>>
> org.apache.shiro.realm.AuthorizingRealm.setAuthorizationCache(AuthorizingR
> ealm.java:109)
> >>>
> >>> at
> >>>
> org.apache.shiro.realm.AuthorizingRealm.initAuthorizationCache(Authorizing
> Realm.java:199)
> >>>
> >>> at
> >>>
> org.apache.shiro.realm.AuthorizingRealm.afterCacheManagerSet(AuthorizingRe
> alm.java:166)
> >>>
> >>> at
> >>>
> org.apache.shiro.realm.CachingRealm.setCacheManager(CachingRealm.java:73)
> >>>
> >>> at
> >>>
> org.apache.shiro.mgt.RealmSecurityManager.applyCacheManagerToRealms(RealmS
> ecurityManager.java:116)
> >>>
> >>> at
> >>>
> org.apache.shiro.mgt.RealmSecurityManager.afterRealmsSet(RealmSecurityMana
> ger.java:86)
> >>>
> >>> at
> >>>
> org.apache.shiro.mgt.AuthenticatingSecurityManager.afterRealmsSet(Authenti
> catingSecurityManager.java:178)
> >>>
> >>> at
> >>>
> org.apache.shiro.mgt.AuthorizingSecurityManager.afterRealmsSet(Authorizing
> SecurityManager.java:129)
> >>>
> >>> at
> >>>
> org.apache.shiro.mgt.RealmSecurityManager.setRealms(RealmSecurityManager.j
> ava:82)
> >>>
> >>> at
> >>>
> org.apache.shiro.config.IniConfiguration.createSecurityManagerForSection(I
> niConfiguration.java:242)
> >>>
> >>> at
> >>>
> org.apache.shiro.config.IniConfiguration.createSecurityManager(IniConfigur
> ation.java:188)
> >>>
> >>> at
> >>>
> org.apache.shiro.config.IniConfiguration.processIni(IniConfiguration.java:
> 172)
> >>>
> >>> at
> >>>
> org.apache.shiro.config.IniConfiguration.process(IniConfiguration.java:161
> )
> >>>
> >>> at
> >>>
> org.apache.shiro.config.IniConfiguration.load(IniConfiguration.java:127)
> >>>
> >>> at
> >>>
> org.apache.shiro.config.TextConfiguration.loadTextConfig(TextConfiguration
> .java:70)
> >>>
> >>> at
> >>>
> org.apache.shiro.config.TextConfiguration.init(TextConfiguration.java:86)
> >>>
> >>> at
> >>>
> org.apache.shiro.config.IniConfiguration.init(IniConfiguration.java:114)
> >>>
> >>> at
> org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:47)
> >>>
> >>> at
> org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:41)
> >>>
> >>> at
> >>>
> org.apache.shiro.web.servlet.ShiroFilter.configure(ShiroFilter.java:322)
> >>>
> >>> at
> >>>
> org.apache.shiro.web.servlet.ShiroFilter.onFilterConfigSet(ShiroFilter.jav
> a:269)
> >>>
> >>> at
> >>>
> org.apache.shiro.web.servlet.OncePerRequestFilter.init(OncePerRequestFilte
> r.java:140)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilt
> erConfig.java:221)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationF
> ilterConfig.java:302)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterC
> onfig.java:78)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:
> 3635)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4222)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java
> :760)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
> >>>
> >>> at
> >>> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
> >>>
> >>> at
> >>>
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:927
> )
> >>>
> >>> at
> >>>
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:8
> 90)
> >>>
> >>> at
> >>> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
> >>>
> >>> at
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150)
> >>>
> >>> at
> >>>
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
> >>>
> >>> at
> >>>
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupp
> ort.java:120)
> >>>
> >>> at
> >>> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
> >>>
> >>> at
> org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
> >>>
> >>> at
> >>> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
> >>>
> >>> at
> >>> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.StandardService.start(StandardService.java:448)
> >>>
> >>> at
> >>> org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
> >>>
> >>> at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
> >>>
> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>
> >>> at
> >>>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> >>>
> >>> at
> >>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
> pl.java:25)
> >>>
> >>> at java.lang.reflect.Method.invoke(Method.java:597)
> >>>
> >>> at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
> >>>
> >>> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
> >>>
> >>>
> >>>
> >>> Andy
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ________________________________
> >>>
> >>> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
> >>> Sent: Monday, August 31, 2009 10:25 AM
> >>> To: shiro-user@incubator.apache.org
> >>> Subject: RE: need help plugging in my own session cache
> >>>
> >>>
> >>>
> >>> I need to get this working, and I'm happy to track it down myself, but
> I
> >>> need some starting direction.
> >>>
> >>>
> >>>
> >>> If I want to use my own cache for storing session data, I know I
> should
> >>> write my own CacheManager and a class that implements Cache. But which
> class
> >>> do I tell to use my own cache? Is it SessionDAO, securityManager, or
> my own
> >>> Realm (in my case a subclass of JDBCRealm)? All three have a
> cacheManager
> >>> property.
> >>>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Andy
> >>>
> >>>
> >>>
> >>> ________________________________
> >>>
> >>> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
> >>> Sent: Friday, August 28, 2009 2:56 PM
> >>> To: shiro-user@incubator.apache.org
> >>> Subject: need help plugging in my own session cache
> >>>
> >>>
> >>>
> >>> Hi again,
> >>>
> >>>
> >>>
> >>> I'm having trouble with specifying my own Cache.
> >>>
> >>> I've specified my own CacheManager and Cache classes in my
> ShiroFilter:
> >>>
> >>>
> >>>
> >>> realmA = com.vonage.auth.VonageAuthenticationRealm
> >>>
> >>> securityManager =
> >>> org.apache.shiro.web.DefaultWebSecurityManager
> >>>
> >>> sessionManager =
> >>> org.apache.shiro.web.session.DefaultWebSessionManager
> >>>
> >>> securityManager.sessionManager = $sessionManager
> >>>
> >>> securityManager.sessionMode = native
> >>>
> >>> #cacheManager =
> org.apache.shiro.cache.DefaultCacheManager
> >>>
> >>> cacheManager =
> >>> com.vonage.auth.VonageDistributedSessionCacheManager
> >>>
> >>> sessionDAO =
> >>> org.apache.shiro.session.mgt.eis.MemorySessionDAO
> >>>
> >>> sessionDAO.cacheManager = $cacheManager
> >>>
> >>> securityManager.sessionDAO = $sessionDAO
> >>>
> >>> securityManager.cacheManager = $cacheManager
> >>>
> >>> securityManager.realm = $realmA
> >>>
> >>> realmA.cacheManager = $cacheManager
> >>>
> >>>
> >>>
> >>> My VonageDistributedSessionCacheManager class simply returns an
> instance of
> >>> my VonageDistributedSessionCache class, which implements the Cache
> >>> interface.
> >>>
> >>>
> >>>
> >>> The problem is that the various methods in my
> VonageDistributedSessionCache
> >>> class (get(), put(), etc) are never being called. By adding tracing, I
> can
> >>> confirm that my VonageDistributedSessionCache constructor is being
> called
> >>> from AuthorizationRealm.initAuthorizationCache(). But when I login to
> my
> >>> servlet, my get() and put() methods are never called. On my first
> login
> >>> attempt to get to my servlet, I have no session and so I'm challenged
> for
> >>> username/password. Then on a second attempt, it lets me through. So
> >>> somewhere Shiro is caching my sessionid, but I don't know where. All I
> know
> >>> is that it's not using the Cache that I told it to :) In fact, I told
> it 3
> >>> times ($cacheManager is mentioned 3 times above)!
> >>>
> >>>
> >>>
> >>> So where is it in Shiro that checks the session cache? I see that
> >>> AuthorizingRealm.initAuthorizationCache() does create an instance of
> my
> >>> VonageDistributedSessionCache class, and calls setAuthorizationCache()
> to
> >>> store it. But I don't see any calls to the corresponding
> >>> getAuthorizationCache() to actually use it.
> >>>
> >>>
> >>>
> >>> I'm not sure if this helps or not, but below is a stack trace from my
> >>> servlet. Somewhere along this chain of calls, somebody should have
> called
> >>> AuthorizingRealm.getAuthorizationCache() but didn't.
> >>>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Andy
> >>>
> >>> ----------------------------------------------------------------------
> ------------------------
> >>>
> >>> at java.lang.Thread.dumpStack(Thread.java:1206)
> >>>
> >>> at
> >>> com.vonage.authenticatorTest.TestServlet1.doGet(TestServlet1.java:15)
> >>>
> >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
> >>>
> >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
> onFilterChain.java:269)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
> Chain.java:188)
> >>>
> >>> at
> >>>
> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChai
> n.java:58)
> >>>
> >>> at
> >>>
> org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:1
> 07)
> >>>
> >>> at
> >>>
> org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.ja
> va:137)
> >>>
> >>> at
> >>>
> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestF
> ilter.java:190)
> >>>
> >>> at
> >>>
> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChai
> n.java:63)
> >>>
> >>> at
> >>>
> org.apache.shiro.web.servlet.ShiroFilter.executeChain(ShiroFilter.java:648
> )
> >>>
> >>> at
> >>>
> org.apache.shiro.web.servlet.ShiroFilter.doFilterInternal(ShiroFilter.java
> :588)
> >>>
> >>> at
> >>>
> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestF
> ilter.java:190)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
> onFilterChain.java:215)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
> Chain.java:188)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
> java:213)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
> java:172)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1
> 27)
> >>>
> >>> at
> >>>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
> 17)
> >>>
> >>> at
> >>>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja
> va:108)
> >>>
> >>> at
> >>>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174
> )
> >>>
> >>> at
> >>>
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
> >>>
> >>> at
> >>>
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proces
> sConnection(Http11BaseProtocol.java:665)
> >>>
> >>> at
> >>>
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.j
> ava:528)
> >>>
> >>> at
> >>>
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollower
> WorkerThread.java:81)
> >>>
> >>> at
> >>>
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.j
> ava:689)
> >>>
> >>> at java.lang.Thread.run(Thread.java:619)
> >>>
> >>>
> >>
> >
Re: need help plugging in my own session cache
Posted by Les Hazlewood <lh...@apache.org>.
This is an order of operations bug. Please open a Jira issue so we
can fix it.
In the mean time, setting the sessionDAO on the securityManager
_before_ setting the cache manager should do the trick.
Here is a configuration that is working for me:
<filter>
<filter-name>ShiroFilter</filter-name>
<filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-class>
<init-param>
<param-name>config</param-name>
<param-value>
[main]
securityManager.sessionMode = native
sessionDAO = org.apache.shiro.session.mgt.eis.MemorySessionDAO
securityManager.sessionDAO = $sessionDAO
cacheManager = TestCacheManager
securityManager.cacheManager = $cacheManager
demoRealm = org.apache.shiro.realm.text.PropertiesRealm
securityManager.realm = $demoRealm
# add [filters] and [urls] sections here as necessary
</param-value>
</init-param>
</filter>
On Wed, Sep 2, 2009 at 1:16 PM, Les Hazlewood<lh...@apache.org> wrote:
> Hi Andy,
>
> There is definitely a bug in the configuration stuff - I'm looking in
> to it to find out what may be wrong. I'll keep you posted.
>
> - Les
>
> On Tue, Sep 1, 2009 at 2:39 PM, Les Hazlewood<lh...@apache.org> wrote:
>> Hi Andy,
>>
>> I'll have to give this a look sometime later tonight or tomorrow when
>> I have time - I'm kinda slammed today. But don't worry - we'll get it
>> working!
>>
>> Best,
>>
>> Les
>>
>> On Tue, Sep 1, 2009 at 11:58 AM, Andy Tripp<An...@vonage.com> wrote:
>>> I made some progress on this issue.
>>>
>>>
>>>
>>> I added tracing to AuthorizingRealm.setAuthorizationCache(). I see that it’s
>>> first being correctly called to set the cache to my “custom”
>>> VonageDistributedSessionCache that I specified in my ShiroFilter. But then,
>>> I see that it’s being called a second time, and getting *reset* to some
>>> instance of SoftHashMapCache.
>>>
>>>
>>>
>>> The stack trace of that 2nd call is below. So the issue is “where in that
>>> stack trace is some code having the audacity to do something that results in
>>> a call to AuthorizingRealm.setAuthorizationCache(), which replaces the
>>> user-specified cache with the default of a SoftHashMapCache?
>>>
>>>
>>>
>>> My (uneducated) guess is that the culprit is the createSecurityManager()
>>> call in IniConfiguration.processIni(). Why would we want to create a
>>> security manager when in the middle of processing configuration data?
>>>
>>>
>>>
>>> In any case, I think the use case is simple: trying to specify your own
>>> CacheManager doesn’t work. Here’s my ShiroFilter:
>>>
>>> # pull in vonage centralized authentication:
>>>
>>> realmA = com.vonage.auth.VonageAuthenticationRealm
>>>
>>> securityManager =
>>> org.apache.shiro.web.DefaultWebSecurityManager
>>>
>>> sessionManager =
>>> org.apache.shiro.web.session.DefaultWebSessionManager
>>>
>>> securityManager.sessionManager = $sessionManager
>>>
>>> securityManager.sessionMode = native
>>>
>>> #cacheManager = org.apache.shiro.cache.DefaultCacheManager
>>>
>>>
>>>
>>> cacheManager =
>>> com.vonage.auth.VonageDistributedSessionCacheManager
>>>
>>> securityManager.cacheManager = $cacheManager
>>>
>>>
>>>
>>> sessionDAO =
>>> org.apache.shiro.session.mgt.eis.MemorySessionDAO
>>>
>>> #sessionDAO.cacheManager = $cacheManager
>>>
>>> securityManager.sessionDAO = $sessionDAO
>>>
>>> securityManager.realm = $realmA
>>>
>>>
>>>
>>> And here’s the stack trace I talked about:
>>>
>>>
>>>
>>>
>>>
>>> java.lang.Exception: Stack trace
>>>
>>> at java.lang.Thread.dumpStack(Thread.java:1206)
>>>
>>> at
>>> org.apache.shiro.realm.AuthorizingRealm.setAuthorizationCache(AuthorizingRealm.java:109)
>>>
>>> at
>>> org.apache.shiro.realm.AuthorizingRealm.initAuthorizationCache(AuthorizingRealm.java:199)
>>>
>>> at
>>> org.apache.shiro.realm.AuthorizingRealm.afterCacheManagerSet(AuthorizingRealm.java:166)
>>>
>>> at
>>> org.apache.shiro.realm.CachingRealm.setCacheManager(CachingRealm.java:73)
>>>
>>> at
>>> org.apache.shiro.mgt.RealmSecurityManager.applyCacheManagerToRealms(RealmSecurityManager.java:116)
>>>
>>> at
>>> org.apache.shiro.mgt.RealmSecurityManager.afterRealmsSet(RealmSecurityManager.java:86)
>>>
>>> at
>>> org.apache.shiro.mgt.AuthenticatingSecurityManager.afterRealmsSet(AuthenticatingSecurityManager.java:178)
>>>
>>> at
>>> org.apache.shiro.mgt.AuthorizingSecurityManager.afterRealmsSet(AuthorizingSecurityManager.java:129)
>>>
>>> at
>>> org.apache.shiro.mgt.RealmSecurityManager.setRealms(RealmSecurityManager.java:82)
>>>
>>> at
>>> org.apache.shiro.config.IniConfiguration.createSecurityManagerForSection(IniConfiguration.java:242)
>>>
>>> at
>>> org.apache.shiro.config.IniConfiguration.createSecurityManager(IniConfiguration.java:188)
>>>
>>> at
>>> org.apache.shiro.config.IniConfiguration.processIni(IniConfiguration.java:172)
>>>
>>> at
>>> org.apache.shiro.config.IniConfiguration.process(IniConfiguration.java:161)
>>>
>>> at
>>> org.apache.shiro.config.IniConfiguration.load(IniConfiguration.java:127)
>>>
>>> at
>>> org.apache.shiro.config.TextConfiguration.loadTextConfig(TextConfiguration.java:70)
>>>
>>> at
>>> org.apache.shiro.config.TextConfiguration.init(TextConfiguration.java:86)
>>>
>>> at
>>> org.apache.shiro.config.IniConfiguration.init(IniConfiguration.java:114)
>>>
>>> at org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:47)
>>>
>>> at org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:41)
>>>
>>> at
>>> org.apache.shiro.web.servlet.ShiroFilter.configure(ShiroFilter.java:322)
>>>
>>> at
>>> org.apache.shiro.web.servlet.ShiroFilter.onFilterConfigSet(ShiroFilter.java:269)
>>>
>>> at
>>> org.apache.shiro.web.servlet.OncePerRequestFilter.init(OncePerRequestFilter.java:140)
>>>
>>> at
>>> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221)
>>>
>>> at
>>> org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:302)
>>>
>>> at
>>> org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:78)
>>>
>>> at
>>> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3635)
>>>
>>> at
>>> org.apache.catalina.core.StandardContext.start(StandardContext.java:4222)
>>>
>>> at
>>> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
>>>
>>> at
>>> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
>>>
>>> at
>>> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
>>>
>>> at
>>> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:927)
>>>
>>> at
>>> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:890)
>>>
>>> at
>>> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
>>>
>>> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150)
>>>
>>> at
>>> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
>>>
>>> at
>>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
>>>
>>> at
>>> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
>>>
>>> at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
>>>
>>> at
>>> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
>>>
>>> at
>>> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
>>>
>>> at
>>> org.apache.catalina.core.StandardService.start(StandardService.java:448)
>>>
>>> at
>>> org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
>>>
>>> at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>
>>> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
>>>
>>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
>>>
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
>>> Sent: Monday, August 31, 2009 10:25 AM
>>> To: shiro-user@incubator.apache.org
>>> Subject: RE: need help plugging in my own session cache
>>>
>>>
>>>
>>> I need to get this working, and I’m happy to track it down myself, but I
>>> need some starting direction.
>>>
>>>
>>>
>>> If I want to use my own cache for storing session data, I know I should
>>> write my own CacheManager and a class that implements Cache. But which class
>>> do I tell to use my own cache? Is it SessionDAO, securityManager, or my own
>>> Realm (in my case a subclass of JDBCRealm)? All three have a cacheManager
>>> property.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Andy
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
>>> Sent: Friday, August 28, 2009 2:56 PM
>>> To: shiro-user@incubator.apache.org
>>> Subject: need help plugging in my own session cache
>>>
>>>
>>>
>>> Hi again,
>>>
>>>
>>>
>>> I’m having trouble with specifying my own Cache.
>>>
>>> I’ve specified my own CacheManager and Cache classes in my ShiroFilter:
>>>
>>>
>>>
>>> realmA = com.vonage.auth.VonageAuthenticationRealm
>>>
>>> securityManager =
>>> org.apache.shiro.web.DefaultWebSecurityManager
>>>
>>> sessionManager =
>>> org.apache.shiro.web.session.DefaultWebSessionManager
>>>
>>> securityManager.sessionManager = $sessionManager
>>>
>>> securityManager.sessionMode = native
>>>
>>> #cacheManager = org.apache.shiro.cache.DefaultCacheManager
>>>
>>> cacheManager =
>>> com.vonage.auth.VonageDistributedSessionCacheManager
>>>
>>> sessionDAO =
>>> org.apache.shiro.session.mgt.eis.MemorySessionDAO
>>>
>>> sessionDAO.cacheManager = $cacheManager
>>>
>>> securityManager.sessionDAO = $sessionDAO
>>>
>>> securityManager.cacheManager = $cacheManager
>>>
>>> securityManager.realm = $realmA
>>>
>>> realmA.cacheManager = $cacheManager
>>>
>>>
>>>
>>> My VonageDistributedSessionCacheManager class simply returns an instance of
>>> my VonageDistributedSessionCache class, which implements the Cache
>>> interface.
>>>
>>>
>>>
>>> The problem is that the various methods in my VonageDistributedSessionCache
>>> class (get(), put(), etc) are never being called. By adding tracing, I can
>>> confirm that my VonageDistributedSessionCache constructor is being called
>>> from AuthorizationRealm.initAuthorizationCache(). But when I login to my
>>> servlet, my get() and put() methods are never called. On my first login
>>> attempt to get to my servlet, I have no session and so I’m challenged for
>>> username/password. Then on a second attempt, it lets me through. So
>>> somewhere Shiro is caching my sessionid, but I don’t know where. All I know
>>> is that it’s not using the Cache that I told it to :) In fact, I told it 3
>>> times ($cacheManager is mentioned 3 times above)!
>>>
>>>
>>>
>>> So where is it in Shiro that checks the session cache? I see that
>>> AuthorizingRealm.initAuthorizationCache() does create an instance of my
>>> VonageDistributedSessionCache class, and calls setAuthorizationCache() to
>>> store it. But I don’t see any calls to the corresponding
>>> getAuthorizationCache() to actually use it.
>>>
>>>
>>>
>>> I’m not sure if this helps or not, but below is a stack trace from my
>>> servlet. Somewhere along this chain of calls, somebody should have called
>>> AuthorizingRealm.getAuthorizationCache() but didn’t.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Andy
>>>
>>> ----------------------------------------------------------------------------------------------
>>>
>>> at java.lang.Thread.dumpStack(Thread.java:1206)
>>>
>>> at
>>> com.vonage.authenticatorTest.TestServlet1.doGet(TestServlet1.java:15)
>>>
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
>>>
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
>>>
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>>>
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>>>
>>> at
>>> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:58)
>>>
>>> at
>>> org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:107)
>>>
>>> at
>>> org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>>>
>>> at
>>> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:190)
>>>
>>> at
>>> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:63)
>>>
>>> at
>>> org.apache.shiro.web.servlet.ShiroFilter.executeChain(ShiroFilter.java:648)
>>>
>>> at
>>> org.apache.shiro.web.servlet.ShiroFilter.doFilterInternal(ShiroFilter.java:588)
>>>
>>> at
>>> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:190)
>>>
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
>>>
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>>>
>>> at
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>>>
>>> at
>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
>>>
>>> at
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>>>
>>> at
>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>>>
>>> at
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
>>>
>>> at
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
>>>
>>> at
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
>>>
>>> at
>>> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
>>>
>>> at
>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
>>>
>>> at
>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
>>>
>>> at
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
>>>
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>>
>>
>
Re: need help plugging in my own session cache
Posted by Les Hazlewood <lh...@apache.org>.
Hi Andy,
There is definitely a bug in the configuration stuff - I'm looking in
to it to find out what may be wrong. I'll keep you posted.
- Les
On Tue, Sep 1, 2009 at 2:39 PM, Les Hazlewood<lh...@apache.org> wrote:
> Hi Andy,
>
> I'll have to give this a look sometime later tonight or tomorrow when
> I have time - I'm kinda slammed today. But don't worry - we'll get it
> working!
>
> Best,
>
> Les
>
> On Tue, Sep 1, 2009 at 11:58 AM, Andy Tripp<An...@vonage.com> wrote:
>> I made some progress on this issue.
>>
>>
>>
>> I added tracing to AuthorizingRealm.setAuthorizationCache(). I see that it’s
>> first being correctly called to set the cache to my “custom”
>> VonageDistributedSessionCache that I specified in my ShiroFilter. But then,
>> I see that it’s being called a second time, and getting *reset* to some
>> instance of SoftHashMapCache.
>>
>>
>>
>> The stack trace of that 2nd call is below. So the issue is “where in that
>> stack trace is some code having the audacity to do something that results in
>> a call to AuthorizingRealm.setAuthorizationCache(), which replaces the
>> user-specified cache with the default of a SoftHashMapCache?
>>
>>
>>
>> My (uneducated) guess is that the culprit is the createSecurityManager()
>> call in IniConfiguration.processIni(). Why would we want to create a
>> security manager when in the middle of processing configuration data?
>>
>>
>>
>> In any case, I think the use case is simple: trying to specify your own
>> CacheManager doesn’t work. Here’s my ShiroFilter:
>>
>> # pull in vonage centralized authentication:
>>
>> realmA = com.vonage.auth.VonageAuthenticationRealm
>>
>> securityManager =
>> org.apache.shiro.web.DefaultWebSecurityManager
>>
>> sessionManager =
>> org.apache.shiro.web.session.DefaultWebSessionManager
>>
>> securityManager.sessionManager = $sessionManager
>>
>> securityManager.sessionMode = native
>>
>> #cacheManager = org.apache.shiro.cache.DefaultCacheManager
>>
>>
>>
>> cacheManager =
>> com.vonage.auth.VonageDistributedSessionCacheManager
>>
>> securityManager.cacheManager = $cacheManager
>>
>>
>>
>> sessionDAO =
>> org.apache.shiro.session.mgt.eis.MemorySessionDAO
>>
>> #sessionDAO.cacheManager = $cacheManager
>>
>> securityManager.sessionDAO = $sessionDAO
>>
>> securityManager.realm = $realmA
>>
>>
>>
>> And here’s the stack trace I talked about:
>>
>>
>>
>>
>>
>> java.lang.Exception: Stack trace
>>
>> at java.lang.Thread.dumpStack(Thread.java:1206)
>>
>> at
>> org.apache.shiro.realm.AuthorizingRealm.setAuthorizationCache(AuthorizingRealm.java:109)
>>
>> at
>> org.apache.shiro.realm.AuthorizingRealm.initAuthorizationCache(AuthorizingRealm.java:199)
>>
>> at
>> org.apache.shiro.realm.AuthorizingRealm.afterCacheManagerSet(AuthorizingRealm.java:166)
>>
>> at
>> org.apache.shiro.realm.CachingRealm.setCacheManager(CachingRealm.java:73)
>>
>> at
>> org.apache.shiro.mgt.RealmSecurityManager.applyCacheManagerToRealms(RealmSecurityManager.java:116)
>>
>> at
>> org.apache.shiro.mgt.RealmSecurityManager.afterRealmsSet(RealmSecurityManager.java:86)
>>
>> at
>> org.apache.shiro.mgt.AuthenticatingSecurityManager.afterRealmsSet(AuthenticatingSecurityManager.java:178)
>>
>> at
>> org.apache.shiro.mgt.AuthorizingSecurityManager.afterRealmsSet(AuthorizingSecurityManager.java:129)
>>
>> at
>> org.apache.shiro.mgt.RealmSecurityManager.setRealms(RealmSecurityManager.java:82)
>>
>> at
>> org.apache.shiro.config.IniConfiguration.createSecurityManagerForSection(IniConfiguration.java:242)
>>
>> at
>> org.apache.shiro.config.IniConfiguration.createSecurityManager(IniConfiguration.java:188)
>>
>> at
>> org.apache.shiro.config.IniConfiguration.processIni(IniConfiguration.java:172)
>>
>> at
>> org.apache.shiro.config.IniConfiguration.process(IniConfiguration.java:161)
>>
>> at
>> org.apache.shiro.config.IniConfiguration.load(IniConfiguration.java:127)
>>
>> at
>> org.apache.shiro.config.TextConfiguration.loadTextConfig(TextConfiguration.java:70)
>>
>> at
>> org.apache.shiro.config.TextConfiguration.init(TextConfiguration.java:86)
>>
>> at
>> org.apache.shiro.config.IniConfiguration.init(IniConfiguration.java:114)
>>
>> at org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:47)
>>
>> at org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:41)
>>
>> at
>> org.apache.shiro.web.servlet.ShiroFilter.configure(ShiroFilter.java:322)
>>
>> at
>> org.apache.shiro.web.servlet.ShiroFilter.onFilterConfigSet(ShiroFilter.java:269)
>>
>> at
>> org.apache.shiro.web.servlet.OncePerRequestFilter.init(OncePerRequestFilter.java:140)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:302)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:78)
>>
>> at
>> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3635)
>>
>> at
>> org.apache.catalina.core.StandardContext.start(StandardContext.java:4222)
>>
>> at
>> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
>>
>> at
>> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
>>
>> at
>> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
>>
>> at
>> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:927)
>>
>> at
>> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:890)
>>
>> at
>> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
>>
>> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150)
>>
>> at
>> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
>>
>> at
>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
>>
>> at
>> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
>>
>> at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
>>
>> at
>> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
>>
>> at
>> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
>>
>> at
>> org.apache.catalina.core.StandardService.start(StandardService.java:448)
>>
>> at
>> org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
>>
>> at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:597)
>>
>> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
>>
>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
>>
>>
>>
>> Andy
>>
>>
>>
>>
>>
>> ________________________________
>>
>> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
>> Sent: Monday, August 31, 2009 10:25 AM
>> To: shiro-user@incubator.apache.org
>> Subject: RE: need help plugging in my own session cache
>>
>>
>>
>> I need to get this working, and I’m happy to track it down myself, but I
>> need some starting direction.
>>
>>
>>
>> If I want to use my own cache for storing session data, I know I should
>> write my own CacheManager and a class that implements Cache. But which class
>> do I tell to use my own cache? Is it SessionDAO, securityManager, or my own
>> Realm (in my case a subclass of JDBCRealm)? All three have a cacheManager
>> property.
>>
>>
>>
>> Thanks,
>>
>> Andy
>>
>>
>>
>> ________________________________
>>
>> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
>> Sent: Friday, August 28, 2009 2:56 PM
>> To: shiro-user@incubator.apache.org
>> Subject: need help plugging in my own session cache
>>
>>
>>
>> Hi again,
>>
>>
>>
>> I’m having trouble with specifying my own Cache.
>>
>> I’ve specified my own CacheManager and Cache classes in my ShiroFilter:
>>
>>
>>
>> realmA = com.vonage.auth.VonageAuthenticationRealm
>>
>> securityManager =
>> org.apache.shiro.web.DefaultWebSecurityManager
>>
>> sessionManager =
>> org.apache.shiro.web.session.DefaultWebSessionManager
>>
>> securityManager.sessionManager = $sessionManager
>>
>> securityManager.sessionMode = native
>>
>> #cacheManager = org.apache.shiro.cache.DefaultCacheManager
>>
>> cacheManager =
>> com.vonage.auth.VonageDistributedSessionCacheManager
>>
>> sessionDAO =
>> org.apache.shiro.session.mgt.eis.MemorySessionDAO
>>
>> sessionDAO.cacheManager = $cacheManager
>>
>> securityManager.sessionDAO = $sessionDAO
>>
>> securityManager.cacheManager = $cacheManager
>>
>> securityManager.realm = $realmA
>>
>> realmA.cacheManager = $cacheManager
>>
>>
>>
>> My VonageDistributedSessionCacheManager class simply returns an instance of
>> my VonageDistributedSessionCache class, which implements the Cache
>> interface.
>>
>>
>>
>> The problem is that the various methods in my VonageDistributedSessionCache
>> class (get(), put(), etc) are never being called. By adding tracing, I can
>> confirm that my VonageDistributedSessionCache constructor is being called
>> from AuthorizationRealm.initAuthorizationCache(). But when I login to my
>> servlet, my get() and put() methods are never called. On my first login
>> attempt to get to my servlet, I have no session and so I’m challenged for
>> username/password. Then on a second attempt, it lets me through. So
>> somewhere Shiro is caching my sessionid, but I don’t know where. All I know
>> is that it’s not using the Cache that I told it to :) In fact, I told it 3
>> times ($cacheManager is mentioned 3 times above)!
>>
>>
>>
>> So where is it in Shiro that checks the session cache? I see that
>> AuthorizingRealm.initAuthorizationCache() does create an instance of my
>> VonageDistributedSessionCache class, and calls setAuthorizationCache() to
>> store it. But I don’t see any calls to the corresponding
>> getAuthorizationCache() to actually use it.
>>
>>
>>
>> I’m not sure if this helps or not, but below is a stack trace from my
>> servlet. Somewhere along this chain of calls, somebody should have called
>> AuthorizingRealm.getAuthorizationCache() but didn’t.
>>
>>
>>
>> Thanks,
>>
>> Andy
>>
>> ----------------------------------------------------------------------------------------------
>>
>> at java.lang.Thread.dumpStack(Thread.java:1206)
>>
>> at
>> com.vonage.authenticatorTest.TestServlet1.doGet(TestServlet1.java:15)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>>
>> at
>> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:58)
>>
>> at
>> org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:107)
>>
>> at
>> org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>>
>> at
>> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:190)
>>
>> at
>> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:63)
>>
>> at
>> org.apache.shiro.web.servlet.ShiroFilter.executeChain(ShiroFilter.java:648)
>>
>> at
>> org.apache.shiro.web.servlet.ShiroFilter.doFilterInternal(ShiroFilter.java:588)
>>
>> at
>> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:190)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>>
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>>
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
>>
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>>
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>>
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
>>
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
>>
>> at
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
>>
>> at
>> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
>>
>> at
>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
>>
>> at
>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
>>
>> at
>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
>>
>> at java.lang.Thread.run(Thread.java:619)
>>
>>
>
Re: need help plugging in my own session cache
Posted by Les Hazlewood <lh...@apache.org>.
Hi Andy,
I'll have to give this a look sometime later tonight or tomorrow when
I have time - I'm kinda slammed today. But don't worry - we'll get it
working!
Best,
Les
On Tue, Sep 1, 2009 at 11:58 AM, Andy Tripp<An...@vonage.com> wrote:
> I made some progress on this issue.
>
>
>
> I added tracing to AuthorizingRealm.setAuthorizationCache(). I see that it’s
> first being correctly called to set the cache to my “custom”
> VonageDistributedSessionCache that I specified in my ShiroFilter. But then,
> I see that it’s being called a second time, and getting *reset* to some
> instance of SoftHashMapCache.
>
>
>
> The stack trace of that 2nd call is below. So the issue is “where in that
> stack trace is some code having the audacity to do something that results in
> a call to AuthorizingRealm.setAuthorizationCache(), which replaces the
> user-specified cache with the default of a SoftHashMapCache?
>
>
>
> My (uneducated) guess is that the culprit is the createSecurityManager()
> call in IniConfiguration.processIni(). Why would we want to create a
> security manager when in the middle of processing configuration data?
>
>
>
> In any case, I think the use case is simple: trying to specify your own
> CacheManager doesn’t work. Here’s my ShiroFilter:
>
> # pull in vonage centralized authentication:
>
> realmA = com.vonage.auth.VonageAuthenticationRealm
>
> securityManager =
> org.apache.shiro.web.DefaultWebSecurityManager
>
> sessionManager =
> org.apache.shiro.web.session.DefaultWebSessionManager
>
> securityManager.sessionManager = $sessionManager
>
> securityManager.sessionMode = native
>
> #cacheManager = org.apache.shiro.cache.DefaultCacheManager
>
>
>
> cacheManager =
> com.vonage.auth.VonageDistributedSessionCacheManager
>
> securityManager.cacheManager = $cacheManager
>
>
>
> sessionDAO =
> org.apache.shiro.session.mgt.eis.MemorySessionDAO
>
> #sessionDAO.cacheManager = $cacheManager
>
> securityManager.sessionDAO = $sessionDAO
>
> securityManager.realm = $realmA
>
>
>
> And here’s the stack trace I talked about:
>
>
>
>
>
> java.lang.Exception: Stack trace
>
> at java.lang.Thread.dumpStack(Thread.java:1206)
>
> at
> org.apache.shiro.realm.AuthorizingRealm.setAuthorizationCache(AuthorizingRealm.java:109)
>
> at
> org.apache.shiro.realm.AuthorizingRealm.initAuthorizationCache(AuthorizingRealm.java:199)
>
> at
> org.apache.shiro.realm.AuthorizingRealm.afterCacheManagerSet(AuthorizingRealm.java:166)
>
> at
> org.apache.shiro.realm.CachingRealm.setCacheManager(CachingRealm.java:73)
>
> at
> org.apache.shiro.mgt.RealmSecurityManager.applyCacheManagerToRealms(RealmSecurityManager.java:116)
>
> at
> org.apache.shiro.mgt.RealmSecurityManager.afterRealmsSet(RealmSecurityManager.java:86)
>
> at
> org.apache.shiro.mgt.AuthenticatingSecurityManager.afterRealmsSet(AuthenticatingSecurityManager.java:178)
>
> at
> org.apache.shiro.mgt.AuthorizingSecurityManager.afterRealmsSet(AuthorizingSecurityManager.java:129)
>
> at
> org.apache.shiro.mgt.RealmSecurityManager.setRealms(RealmSecurityManager.java:82)
>
> at
> org.apache.shiro.config.IniConfiguration.createSecurityManagerForSection(IniConfiguration.java:242)
>
> at
> org.apache.shiro.config.IniConfiguration.createSecurityManager(IniConfiguration.java:188)
>
> at
> org.apache.shiro.config.IniConfiguration.processIni(IniConfiguration.java:172)
>
> at
> org.apache.shiro.config.IniConfiguration.process(IniConfiguration.java:161)
>
> at
> org.apache.shiro.config.IniConfiguration.load(IniConfiguration.java:127)
>
> at
> org.apache.shiro.config.TextConfiguration.loadTextConfig(TextConfiguration.java:70)
>
> at
> org.apache.shiro.config.TextConfiguration.init(TextConfiguration.java:86)
>
> at
> org.apache.shiro.config.IniConfiguration.init(IniConfiguration.java:114)
>
> at org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:47)
>
> at org.apache.shiro.util.LifecycleUtils.init(LifecycleUtils.java:41)
>
> at
> org.apache.shiro.web.servlet.ShiroFilter.configure(ShiroFilter.java:322)
>
> at
> org.apache.shiro.web.servlet.ShiroFilter.onFilterConfigSet(ShiroFilter.java:269)
>
> at
> org.apache.shiro.web.servlet.OncePerRequestFilter.init(OncePerRequestFilter.java:140)
>
> at
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221)
>
> at
> org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:302)
>
> at
> org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:78)
>
> at
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3635)
>
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4222)
>
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
>
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
>
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
>
> at
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:927)
>
> at
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:890)
>
> at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
>
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150)
>
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
>
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
>
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
>
> at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
>
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
>
> at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
>
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:448)
>
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
>
> at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
>
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
>
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
>
>
>
> Andy
>
>
>
>
>
> ________________________________
>
> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
> Sent: Monday, August 31, 2009 10:25 AM
> To: shiro-user@incubator.apache.org
> Subject: RE: need help plugging in my own session cache
>
>
>
> I need to get this working, and I’m happy to track it down myself, but I
> need some starting direction.
>
>
>
> If I want to use my own cache for storing session data, I know I should
> write my own CacheManager and a class that implements Cache. But which class
> do I tell to use my own cache? Is it SessionDAO, securityManager, or my own
> Realm (in my case a subclass of JDBCRealm)? All three have a cacheManager
> property.
>
>
>
> Thanks,
>
> Andy
>
>
>
> ________________________________
>
> From: Andy Tripp [mailto:Andrew.Tripp@vonage.com]
> Sent: Friday, August 28, 2009 2:56 PM
> To: shiro-user@incubator.apache.org
> Subject: need help plugging in my own session cache
>
>
>
> Hi again,
>
>
>
> I’m having trouble with specifying my own Cache.
>
> I’ve specified my own CacheManager and Cache classes in my ShiroFilter:
>
>
>
> realmA = com.vonage.auth.VonageAuthenticationRealm
>
> securityManager =
> org.apache.shiro.web.DefaultWebSecurityManager
>
> sessionManager =
> org.apache.shiro.web.session.DefaultWebSessionManager
>
> securityManager.sessionManager = $sessionManager
>
> securityManager.sessionMode = native
>
> #cacheManager = org.apache.shiro.cache.DefaultCacheManager
>
> cacheManager =
> com.vonage.auth.VonageDistributedSessionCacheManager
>
> sessionDAO =
> org.apache.shiro.session.mgt.eis.MemorySessionDAO
>
> sessionDAO.cacheManager = $cacheManager
>
> securityManager.sessionDAO = $sessionDAO
>
> securityManager.cacheManager = $cacheManager
>
> securityManager.realm = $realmA
>
> realmA.cacheManager = $cacheManager
>
>
>
> My VonageDistributedSessionCacheManager class simply returns an instance of
> my VonageDistributedSessionCache class, which implements the Cache
> interface.
>
>
>
> The problem is that the various methods in my VonageDistributedSessionCache
> class (get(), put(), etc) are never being called. By adding tracing, I can
> confirm that my VonageDistributedSessionCache constructor is being called
> from AuthorizationRealm.initAuthorizationCache(). But when I login to my
> servlet, my get() and put() methods are never called. On my first login
> attempt to get to my servlet, I have no session and so I’m challenged for
> username/password. Then on a second attempt, it lets me through. So
> somewhere Shiro is caching my sessionid, but I don’t know where. All I know
> is that it’s not using the Cache that I told it to :) In fact, I told it 3
> times ($cacheManager is mentioned 3 times above)!
>
>
>
> So where is it in Shiro that checks the session cache? I see that
> AuthorizingRealm.initAuthorizationCache() does create an instance of my
> VonageDistributedSessionCache class, and calls setAuthorizationCache() to
> store it. But I don’t see any calls to the corresponding
> getAuthorizationCache() to actually use it.
>
>
>
> I’m not sure if this helps or not, but below is a stack trace from my
> servlet. Somewhere along this chain of calls, somebody should have called
> AuthorizingRealm.getAuthorizationCache() but didn’t.
>
>
>
> Thanks,
>
> Andy
>
> ----------------------------------------------------------------------------------------------
>
> at java.lang.Thread.dumpStack(Thread.java:1206)
>
> at
> com.vonage.authenticatorTest.TestServlet1.doGet(TestServlet1.java:15)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>
> at
> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:58)
>
> at
> org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:107)
>
> at
> org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>
> at
> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:190)
>
> at
> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:63)
>
> at
> org.apache.shiro.web.servlet.ShiroFilter.executeChain(ShiroFilter.java:648)
>
> at
> org.apache.shiro.web.servlet.ShiroFilter.doFilterInternal(ShiroFilter.java:588)
>
> at
> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:190)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
>
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
>
> at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
>
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
>
> at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
>
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
>
> at java.lang.Thread.run(Thread.java:619)
>
>