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
