Is this approach applicable for Shiro 1.1 through 1.3?
Thanks, Chris On 1/23/2012 1:46 PM, Les Hazlewood wrote:
Hi Chris, I just read your other email, but let me clarify in case I'm interpreting this incorrectly: you've set up a Shiro SecurityManager with a Realm in your app (outside of web.xml) and now you want the realm accessible to the web tier via web.xml. If that's the case, you will have two SecurityManagers created and running - one for the non-web code and one for the web code. This is perfectly ok by the way, but I clarify because in a web environment, you definitely want a WebSecurityManager and corresponding web-related code to execute (WebSubject creation, etc). One of the easiest ways to do this is to create a org.apache.shiro.util.Factory implementation that looks up your Realm from a known location and returns it when getInstance() is invoked. For example: [main] lookedUpRealm = com.foo.my.shiro.RealmFactory securityManager.realms = $lookedUpRealm #end .ini Your com.foo.my.shiro.RealmFactory implementation's getInstance() call would return your Realm based on that known location. Another approach is to create a custom MutableWebEnvironment class that looks up things based on a ServletContext. For example, you could subclass the IniWebEnvironment implementation and override the 'createWebSecurityManager' to create a new WebSecurityManager instance with the objects you acquired based on the ServletContext. You would specify that custom class in web.xml as described here: http://shiro.apache.org/web.html#Web-Custom%257B%257BWebEnvironment%257D%257DClass The Filter approach is easier, so I'd go with that barring any problems. If, along the way, you see a way to make this even easier, let us know and we can try to add an improvement for 1.3.x. HTH,
