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.
