You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by jhericks <ja...@jasonerickson.com> on 2011/05/17 01:41:48 UTC
Order of setting sessionMode matters
I just got done working through an issue trying to get single sign-on working
with EhCacheManager, following some examples I found elsewhere on the
mailing list (except I was using Spring configuration). It wasn't working
for me at first with this:
<bean id="securityManager"
class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
<property name="realm" ref="factorlabRealm" />
<property name="subjectFactory" ref="factorlabSubjectFactory" />
<property name="cacheManager" ref="ssoCacheManager" />
<property name="sessionManager" ref="sessionManager" />
<property name="sessionMode" value="native" />
</bean>
After lots of debugging, I got it to work with this:
<bean id="securityManager"
class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
<property name="sessionMode" value="native" />
<property name="realm" ref="factorlabRealm" />
<property name="subjectFactory" ref="factorlabSubjectFactory" />
<property name="cacheManager" ref="ssoCacheManager" />
<property name="sessionManager" ref="sessionManager" />
</bean>
The difference is moving the sessionMode to earlier in the property list,
because the setter for sessionMode was replacing my configured
sessionManager with a new DefaultWebSessionManager.
This seems pretty fragile. Is it a bug? This was with version 1.0.0. Has
it been addressed in later versions?
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Order-of-setting-sessionMode-matters-tp6371025p6371025.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Order of setting sessionMode matters
Posted by jhericks <ja...@jasonerickson.com>.
OK, I created it: https://issues.apache.org/jira/browse/SHIRO-297
On May 16, 2011, at 5:50 PM, Les Hazlewood-2 [via Shiro User] wrote:
> Actually, the more that I think about it, I think wholesale removing
> the property would be a good idea - or at least make it a
> read-only/'computed' property. We'd just need to update the
> documentation and make a backwards-incompatibility note, showing how
> to achieve the same thing with injection (even in INI it is easy to do
> this).
>
> On Mon, May 16, 2011 at 5:46 PM, Les Hazlewood <[hidden email]> wrote:
>
> > Hi Jason,
> >
> > The 'sessionMode' property was intended to be a convenience trigger to
> > set up an appropriate SessionManager automatically (for example, if
> > configuring with more primitive mechanisms, like with INI).
> >
> > Since you're explicitly configuring a sessionManager directly, you
> > shouldn't need to set it. I see however that a very small amount of
> > logic (isHttpSessionMode()) is dependent upon it being set correctly,
> > which is unfortunate.
> >
> > There are two ways this can probably be solved:
> >
> > 1. The value is automatically set to 'native' if injecting a
> > NativeSessionManager instance (which DefaultWebSessionManager
> > implements).
> > 2. A WebSecurityManagerFactoryBean implementation could be created
> > for Spring to 'cache' all of the configured settings until building is
> > necessary, at which time those things can be set properly.
> >
> > Maybe both would be a good idea.
> >
> > Can you please open a Jira issue for this? I would consider this a
> > bug for sure. It would be a fairly easy fix though...
> >
> > Thanks,
> >
> > Les
> >
> > On Mon, May 16, 2011 at 4:41 PM, jhericks <[hidden email]> wrote:
> >> I just got done working through an issue trying to get single sign-on working
> >> with EhCacheManager, following some examples I found elsewhere on the
> >> mailing list (except I was using Spring configuration). It wasn't working
> >> for me at first with this:
> >>
> >>
> >> <bean id="securityManager"
> >> class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
> >> <property name="realm" ref="factorlabRealm" />
> >> <property name="subjectFactory" ref="factorlabSubjectFactory" />
> >> <property name="cacheManager" ref="ssoCacheManager" />
> >> <property name="sessionManager" ref="sessionManager" />
> >> <property name="sessionMode" value="native" />
> >> </bean>
> >>
> >>
> >> After lots of debugging, I got it to work with this:
> >>
> >>
> >> <bean id="securityManager"
> >> class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
> >> <property name="sessionMode" value="native" />
> >> <property name="realm" ref="factorlabRealm" />
> >> <property name="subjectFactory" ref="factorlabSubjectFactory" />
> >> <property name="cacheManager" ref="ssoCacheManager" />
> >> <property name="sessionManager" ref="sessionManager" />
> >> </bean>
> >>
> >>
> >> The difference is moving the sessionMode to earlier in the property list,
> >> because the setter for sessionMode was replacing my configured
> >> sessionManager with a new DefaultWebSessionManager.
> >>
> >> This seems pretty fragile. Is it a bug? This was with version 1.0.0. Has
> >> it been addressed in later versions?
> >>
> >> --
> >> View this message in context: http://shiro-user.582556.n2.nabble.com/Order-of-setting-sessionMode-matters-tp6371025p6371025.html
> >> Sent from the Shiro User mailing list archive at Nabble.com.
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://shiro-user.582556.n2.nabble.com/Order-of-setting-sessionMode-matters-tp6371025p6371137.html
> To unsubscribe from Order of setting sessionMode matters, click here.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Order-of-setting-sessionMode-matters-tp6371025p6371197.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Order of setting sessionMode matters
Posted by Les Hazlewood <lh...@apache.org>.
Actually, the more that I think about it, I think wholesale removing
the property would be a good idea - or at least make it a
read-only/'computed' property. We'd just need to update the
documentation and make a backwards-incompatibility note, showing how
to achieve the same thing with injection (even in INI it is easy to do
this).
On Mon, May 16, 2011 at 5:46 PM, Les Hazlewood <lh...@apache.org> wrote:
> Hi Jason,
>
> The 'sessionMode' property was intended to be a convenience trigger to
> set up an appropriate SessionManager automatically (for example, if
> configuring with more primitive mechanisms, like with INI).
>
> Since you're explicitly configuring a sessionManager directly, you
> shouldn't need to set it. I see however that a very small amount of
> logic (isHttpSessionMode()) is dependent upon it being set correctly,
> which is unfortunate.
>
> There are two ways this can probably be solved:
>
> 1. The value is automatically set to 'native' if injecting a
> NativeSessionManager instance (which DefaultWebSessionManager
> implements).
> 2. A WebSecurityManagerFactoryBean implementation could be created
> for Spring to 'cache' all of the configured settings until building is
> necessary, at which time those things can be set properly.
>
> Maybe both would be a good idea.
>
> Can you please open a Jira issue for this? I would consider this a
> bug for sure. It would be a fairly easy fix though...
>
> Thanks,
>
> Les
>
> On Mon, May 16, 2011 at 4:41 PM, jhericks <ja...@jasonerickson.com> wrote:
>> I just got done working through an issue trying to get single sign-on working
>> with EhCacheManager, following some examples I found elsewhere on the
>> mailing list (except I was using Spring configuration). It wasn't working
>> for me at first with this:
>>
>>
>> <bean id="securityManager"
>> class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
>> <property name="realm" ref="factorlabRealm" />
>> <property name="subjectFactory" ref="factorlabSubjectFactory" />
>> <property name="cacheManager" ref="ssoCacheManager" />
>> <property name="sessionManager" ref="sessionManager" />
>> <property name="sessionMode" value="native" />
>> </bean>
>>
>>
>> After lots of debugging, I got it to work with this:
>>
>>
>> <bean id="securityManager"
>> class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
>> <property name="sessionMode" value="native" />
>> <property name="realm" ref="factorlabRealm" />
>> <property name="subjectFactory" ref="factorlabSubjectFactory" />
>> <property name="cacheManager" ref="ssoCacheManager" />
>> <property name="sessionManager" ref="sessionManager" />
>> </bean>
>>
>>
>> The difference is moving the sessionMode to earlier in the property list,
>> because the setter for sessionMode was replacing my configured
>> sessionManager with a new DefaultWebSessionManager.
>>
>> This seems pretty fragile. Is it a bug? This was with version 1.0.0. Has
>> it been addressed in later versions?
>>
>> --
>> View this message in context: http://shiro-user.582556.n2.nabble.com/Order-of-setting-sessionMode-matters-tp6371025p6371025.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
Re: Order of setting sessionMode matters
Posted by Les Hazlewood <lh...@apache.org>.
Hi Jason,
The 'sessionMode' property was intended to be a convenience trigger to
set up an appropriate SessionManager automatically (for example, if
configuring with more primitive mechanisms, like with INI).
Since you're explicitly configuring a sessionManager directly, you
shouldn't need to set it. I see however that a very small amount of
logic (isHttpSessionMode()) is dependent upon it being set correctly,
which is unfortunate.
There are two ways this can probably be solved:
1. The value is automatically set to 'native' if injecting a
NativeSessionManager instance (which DefaultWebSessionManager
implements).
2. A WebSecurityManagerFactoryBean implementation could be created
for Spring to 'cache' all of the configured settings until building is
necessary, at which time those things can be set properly.
Maybe both would be a good idea.
Can you please open a Jira issue for this? I would consider this a
bug for sure. It would be a fairly easy fix though...
Thanks,
Les
On Mon, May 16, 2011 at 4:41 PM, jhericks <ja...@jasonerickson.com> wrote:
> I just got done working through an issue trying to get single sign-on working
> with EhCacheManager, following some examples I found elsewhere on the
> mailing list (except I was using Spring configuration). It wasn't working
> for me at first with this:
>
>
> <bean id="securityManager"
> class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
> <property name="realm" ref="factorlabRealm" />
> <property name="subjectFactory" ref="factorlabSubjectFactory" />
> <property name="cacheManager" ref="ssoCacheManager" />
> <property name="sessionManager" ref="sessionManager" />
> <property name="sessionMode" value="native" />
> </bean>
>
>
> After lots of debugging, I got it to work with this:
>
>
> <bean id="securityManager"
> class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
> <property name="sessionMode" value="native" />
> <property name="realm" ref="factorlabRealm" />
> <property name="subjectFactory" ref="factorlabSubjectFactory" />
> <property name="cacheManager" ref="ssoCacheManager" />
> <property name="sessionManager" ref="sessionManager" />
> </bean>
>
>
> The difference is moving the sessionMode to earlier in the property list,
> because the setter for sessionMode was replacing my configured
> sessionManager with a new DefaultWebSessionManager.
>
> This seems pretty fragile. Is it a bug? This was with version 1.0.0. Has
> it been addressed in later versions?
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Order-of-setting-sessionMode-matters-tp6371025p6371025.html
> Sent from the Shiro User mailing list archive at Nabble.com.