Hi Alex, When Shiro processes a web request it creates a Subject instance reflecting the current user and binds that instance to the thread for the duration of the request.
In order to create a Subject instance, it must have access to the Shiro SecurityManager. (It uses the Subject.Builder to do this). So, to ensure this happens correctly, you have one of two options: 1) Ensure the ShiroFilter is configured appropriately and that it filters all requests. When using Spring, this means defining the ShiroFilterFactoryBean in your spring.xml config file. or 2) call SecurityUtils.setSecurityManager so your SecurityManager instance is available as a static singleton. When the Subject.Builder creates a Subject for the incoming request, it will fall back to the static SecurityManager if one is not supplied to it explicitly. #1 is the correct solution for web applications, as the ShiroFilter should filter every request, and it will automatically set up the Subject correctly. However for an application that services non HTTP requests (or doesn't support the Servlet Request/Response API) - e.g. RMI or some other remoting mechanism - something needs to duplicate this same CreateSubject-Bind-Invoke-Unbind logic that is performed by the ShiroFilter in a web app. #1 is certainly more elegant, as static singletons are often a messy solution (e.g. classloader issues), but it requires you to set up a filtering mechanism (e.g. Servlet Filter or AOP Advice) for any endpoint that may process an externally initiated request or invocation. For Spring non-HTTP apps, this is covered by the Shiro's support for Spring remoting: http://shiro.apache.org/spring.html. The SecureRemoteInvocationExecutor is the thing that inspects the incoming remote method invocation, builds a Subject based on that, binds it to the thread, invokes the intended method, and then finally unbinds the Subject. If you need to do something similar for your own non-web-based application, you can look at its source code and duplicate its logic for your own remoting mechanism: http://svn.apache.org/repos/asf/shiro/trunk/support/spring/src/main/java/org/apache/shiro/spring/remoting/SecureRemoteInvocationExecutor.java So it sounds like you would need to duplicate this logic in a SmartFox-specific way. That is, some component that can intercept all requests into SmartFox. In summary: 1. Create your SmartFox-specific interceptor that filters/intercepts all inbound SmartFox requests. 2. Ensure this component has access to your configured SecurityManager 3. Perform the same logic as the SecureRemoteInvocationExecutor (calling subject.execute) HTH, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com On Wed, Sep 7, 2011 at 1:50 AM, Alex Vasilenko <[email protected]> wrote: > Hello, > I have a setup, already explained in this topic > http://shiro-user.582556.n2.nabble.com/multiple-realms-configuration-td6742675.html >> >> The project, I'm working on, is a MMO game with 2 applications (in fact >> there are more, but it's out of scope): web application and MMO server >> itself. MMO server is based on Smartfox and uses custom shiro realm. Web >> realm is based on shiro web extension. Sessions DAO and session id is the >> same for both applications. > > Spring 3.0.5 and shiro 1.1 are used to integrate MMO and web applications. > Both MMO and web application use the same session DAO, defined in spring: > > mmo application definition - https://gist.github.com/1200069 > web application definition - https://gist.github.com/1200071 > > Web application context has mmo context, as a parent. Using embedded jetty > as application server and beans are shared between contexts. > Unless I bind explicitly web security manager, using security utils > (https://gist.github.com/1200074) session DAO bean is not shared. Security > manager uses own session dao, ignoring the one, defined in spring. > Debugging shows that web application even doesn't use web security manager > defined in spring. Another instance of DefaultSecurityManager. If it's > parent mmo manager, then it should have at least the same session dao. > Is it a correct behavior? Shiro-spring documentation > (http://shiro.apache.org/spring.html) doesn't say anything about binding > security manager. > Should I bind explicitly or let shiro decide? > Thanks, > Alexandr Vasilenko > Web Developer > Skype:menterr > mob: +38097-611-45-99
