On Fri, Mar 4, 2011 at 3:39 PM, Michael Angelo <[email protected]> wrote: >> (specify this realm in your Shiro SecurityManager config of course - >> shiro.ini, spring, etc). > > How can I set the 'ini' info in the spring config .xml? I swear I saw an > example of that somewhere, but now I can't find it. I want to set the cache > there.
Ah, you're using Spring - nice. In that case, you don't even need INI - IoC containers like Spring, Guice, Tapestry, etc are much better at handling complex object graph configuration. The INI is just Shiro's "lowest common denominator" to be used in any environment, aka "poor man's" dependency injection if you can't (or don't want to) use the more powerful mechanisms. So, to that end, you'll want to read our Spring documentation if you haven't already: http://shiro.apache.org/spring.html In there, you'll see the the ShiroFilterFactoryBean referencing the SecurityManager bean definition. In the SecurityManager bean definition is where you'll want to specify your realms: <bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager"> <property name="realm" ref="myTrustedOracleSsoRealm"/> ... <property name="cacheManager" ref="myCacheManager"/> ... </bean> > The issue is when a user comes to the first page (where they MUST set their > 'region' info) there needs to be a sole role just for that - the home page. > This is missing. > > After they set the 'region' info I will notify listeners, but that's all that > I have in my head for now. Rather than try the ThreadLocal approch fist, what > do you think about attching the 'region' info to the Shiro Session object? Can > I obtain the current session for the current user from the Realm to adjust the > query executed by the DAO? That seems simple enough. Absolutely - that's a fine approach and will work quite well. The ThreadLocal approach is good if you need a stateless system (e.g. REST environments). > I am almost there!! You have been an amazing help!! Awesome - I'm glad to hear you're almost there :) Hopefully this has been a good insight into what Shiro is capable of in a short amount of time with a bit of help. In the next versions of Shiro, we'll focus even more on cleaning up the need to subclass for these special cases. You'll find even more pluggability where possible. Cheers, -- Les Hazlewood Founder, Katasoft, Inc. Application Security Products & Professional Apache Shiro Support and Training: http://www.katasoft.com
