I'm not currently able to go digging about the sources so I'm just reaching back in my memory here - maybe try:
"roles[role1, role2]" If this is a filter chain, that parsing will try to grab the commas, which I would imagine will screw it up. The quotes "should" protect them. -----Original Message----- From: mangelo [mailto:[email protected]] Sent: Sat 3/5/2011 11:45 AM To: [email protected] Subject: RE: Single Sign On (SSO), Spring, Hibernate Help. That's exactly what I was going to do, but when you try to use roles in this way it throw an error as if it does not like the syntax (ie roles[role1,role2...]). I am about to do this. I just hope it takes it ok. Thanks. ------ Original Message ------ Received: 09:00 AM EST, 03/05/2011 From: "Jared Bunting [via Shiro Developer]" <[email protected]> To: mangelo <[email protected]> Subject: RE: Single Sign On (SSO), Spring, Hibernate Help. > > > On 03/04/2011 09:58 PM, mangelo wrote: > > I've got most of this working, but the most obvious thing has caused the > > latest roadblock! > > > > I assumed this was possible: > > > > /someurl/** = roles[RECORDS_MANAGEMENT_ADMIN, RECORDS_MANAGEMENT_ENTRY, > > RECORDS_MANAGEMENT_USER] > > I haven't used the roles filter, but I see no reason that this wouldn't work from looking at the code. However, it does treat this as an "AND" - this configuration would require a user to have all three of those roles in order to be allowed. Perhaps that is not what you intended? > > > > > I thought you would be able to specify more than one role given the 'roles' > > filter name. > > > > Please tell me that there is a simple work-around. I don't think I can > > introduce permissions. > > > > In my opinion, one of the greatest strengths of Shiro is the ability to extend the framework quickly and easily to do whatever I want, while still taking advantage of the stock parts that work for me. That being said, I'd say that the simplest work-around is to write your own roles authorization filter. Take a look at the RolesAuthorizationFilter source (it's really straightforward). The last line is: > > return subject.hasAllRoles(roles); > > Copy the method to your own filter class, change that line to: > > boolean[] alloweds = subject.hasRoles(roles); > for(boolean allowed: alloweds) { > if(allowed) return true; > } > return false; > > Add the filter as a spring bean. Then I believe you can add it to your filter chain by its bean name. There might be another step - I haven't had the chance to actually use Shiro with Spring in production. > > > > If the tablib does it, why couldn't it be done here? > > > > Mike. > > > > > > > > > > ------ Original Message ------ > > Received: 07:15 PM EST, 03/04/2011 > > From: "Les Hazlewood-2 [via Shiro Developer]" > > <[email protected]> > > To: mangelo <[email protected]> > > Subject: Re: Single Sign On (SSO), Spring, Hibernate Help. > > > >> > >> > >> P.S. The one place in my Spring apps where I still like to use text > >> config is in the ShiroFilterFactoryBean's 'filterChainDefinitions' > >> property. It is a much nicer (and more succinct) way of configuring > >> filter chains than using web.xml. I configure everything else as > >> normal Spring XML though. > >> > >> On Fri, Mar 4, 2011 at 4:12 PM, Les Hazlewood <[email protected]> > > wrote: > >>> 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 > >> > >> > >> _______________________________________________ > >> If you reply to this email, your message will be added to the discussion > > below: > >> > > http://shiro-developer.582600.n2.nabble.com/Single-Sign-On-SSO-Spring-Hibernate-Help-tp6088874p6090566.html > >> > >> To unsubscribe from Single Sign On (SSO), Spring, Hibernate Help., visit > > http://shiro-developer.582600.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=6088874&code=bWlrZWFuZ2Vsb0B1c2EubmV0fDYwODg4NzR8LTE1NDY4NDI3NDY= > > > > > > > > > > -- > > View this message in context: http://shiro-developer.582600.n2.nabble.com/Single-Sign-On-SSO-Spring-Hibernate-Help-tp6088874p6090948.html > > Sent from the Shiro Developer mailing list archive at Nabble.com. > > > _______________________________________________ > If you reply to this email, your message will be added to the discussion below: > http://shiro-developer.582600.n2.nabble.com/Single-Sign-On-SSO-Spring-Hibernate-Help-tp6088874p6091844.html > > To unsubscribe from Single Sign On (SSO), Spring, Hibernate Help., visit http://shiro-developer.582600.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=6088874&code=bWlrZWFuZ2Vsb0B1c2EubmV0fDYwODg4NzR8LTE1NDY4NDI3NDY= -- View this message in context: http://shiro-developer.582600.n2.nabble.com/Single-Sign-On-SSO-Spring-Hibernate-Help-tp6088874p6092147.html Sent from the Shiro Developer mailing list archive at Nabble.com.
