Have a look at https://issues.apache.org/jira/browse/SHIRO-312. I think it addresses your #2. The "sessionMode" property has been deprecated in 1.2. So basically, you won't use it and will just set your SessionManager.
-Jared On 09/16/2011 09:17 AM, Alex Vasilenko wrote: > Resolved the problem, sharing with others. > > First of all: Les, you were right. Yes, it's not a good idea to bind > SecurityManager as singleton, using SecurityUtils.setSecurityManager. > MMO and web servers should have 2 different security managers. And you told > the solution - bind to threads. > > Second: I thought there was 1 bug in shiro, but there were 2 bugs in mine > application :) > > 1. Incorrect set of spring parent context in web application. You can > compare difference in gist - https://gist.github.com/1222182 . Context's > BeanFactory is already initialized in customizeContext() and setParent > doesn't update it. The bug was, that bean definitions were correctly read, > but bean singletons weren't merged with parent context (because BeanFactory > didn't know anything about parent) > 2. DefaultWebSecurityManager behavior, when session mode is changed. It > simply ignores, the session manager, set by setSessionManager() method and > creates a new one. Take a look at this portion of DefaultWebSecurityManager > - https://gist.github.com/1222206 > > So the conclusion is that it's impossible to inject own session manager, if > session mode is non-default. For myself I've created such a dirty hack - > https://gist.github.com/122221 . Very ugly, I know :) > > As another solution: check session mode on setting session manager and check > session manager on setting session mode. Throw exception if session mode > doesn't correspond to session manager or vice versa, instead of silently > recreating session manager instance. > > In Spring it can be done even easily - implement InitializingBean and check > session mode and session manager in afterPropertiesSet() method. > > Les, what do you think about solutions? > > Thanks, > Alex > > 2011/9/7 Les Hazlewood <[email protected]> > >> On Wed, Sep 7, 2011 at 11:06 AM, Alex Vasilenko <[email protected]> >> wrote: >>> Hello Les, >>> I've added shiro filter setup, that I've missed previous time. First I've >>> tried using #1 approach only for web application. But it didn't work. >> Hybrid >>> #1 with #2 works. >>> However #1 worked ok (correct realm, correct credentials matcher, etc), >>> until I figured out, that security manager was different. It was weird. >>> Because if it was using parent security manager then it had different >> realm >>> and different credentials matcher. But there were only 2 differences - >>> DefaultSecurityManager instance instead of DefaultWebSecurityManager and >>> different session DAO. >>> That is why I've posted it here, thought #1 and #2 should be combined by >>> default. >> If you use the ShiroFilterFactoryBean in spring.xml, you inject it >> with the DefaultWebSecurityManager bean. Once you do this, there is >> no need to call SecurityUtils.setSecurityManager because the filter >> will have the injected one and use it for all requests. >> >> Or is it possible that SmartFox invokes things asynchronously that are >> not triggered in the request thread? If yes, calling >> SecurityUtils.setSecurityManager may be your best option. >> >> However, if SmartFox does do things asynchronously (out of the request >> thread), and it does so by using an ExecutorService, you can configure >> one of Shiro's SubjectAware* ExecutorService implementations to >> automate subject 'handoff' across threads. This is the only way at >> the moment to ensure a Subject 'follows' threads related to >> subject-initiated invocations. >> >>> For Smartfox I'm using something similar to what you have already >> described. >>> There's something similar to Servlet Filters, where I bind subject to >>> current thread - https://gist.github.com/1201270 . >>> It's impossible to unbind later, because Smartfox doesn't provider >>> post-filter. But it works ok, because I bind or clear subject on each >>> request. >> Hrm - too bad you can't use Subject.Builder and subject.execute. >> Subject.execute will automatically unbind the Subject instance after >> the invocation completes (or errors). But the ThreadState mechanism >> is fine if you can't - it's just a tad more work. >> >> Cheers, >> >> Les >>
