You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by larsmjoh <la...@gmail.com> on 2012/12/17 13:30:11 UTC
Conflict with AppServer JSESSIONID
Hi,
We have added Shiro to an existing enterprise application. Technically, it's
several web applications. We implement SSO by caching Shiro native sessions
via Coherence (we've built a CacheManager, quite similar to Shiro's built in
EhCacheManager). In order to share the JSESSIONID-cookie over the apps'
context roots, it's path is set to '/'. The apps run on WebLogic 10.3.6.
The problem: As Shiro sets its JSESSIONID-cookie on '/', so does WebLogic.
It does this regardless of whether Shiro sets the cookie on '/' or on the
apps ctx root. This leads to unpredictable behavior, depending on which
version of the cookie gets read or written in which order.
One solution is to rename Shiro's session cookie. However, for various other
reasons, we'd rather keep the JSESSIONID name. Preferably, we'd like to stop
WebLogic from setting it's own session cookie.
I though Shiro native sessions was supposed to prevent this? Is this a
peculiarity of (this version?) of WebLogic or does it occur on other
appservers/servlet containers..?
Regards,
Lars
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Conflict-with-AppServer-JSESSIONID-tp7578066.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Conflict with AppServer JSESSIONID
Posted by larsmjoh <la...@gmail.com>.
Hi Les,
Makes sense. I think I have a prime suspect in my web.xml
Thanks,
Lars
On 21 Dec 2012 17:59, "Les Hazlewood-2 [via Shiro User]" <
ml-node+s582556n7578091h66@n2.nabble.com> wrote:
> Hi Lars,
>
> The only time I've ever seen this in other environments is if the
> Shiro Filter does not sit 'high' enough in the filter chain.
>
> That is, _something_ before the ShiroFilter is probably calling
> request.getSession(). When the ShiroFilter executes, it wraps the
> request object to ensure it can intercept request.getSession() calls
> to use Shiro's session mechanisms and not the servlet container's.
>
> Something executing before Shiro is probably interacting with the
> yet-to-be-wrapped request and starting a container session.
>
> HTH!
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
> Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
>
> On Mon, Dec 17, 2012 at 4:30 AM, larsmjoh <[hidden email]<http://user/SendEmail.jtp?type=node&node=7578091&i=0>>
> wrote:
>
> > Hi,
> >
> > We have added Shiro to an existing enterprise application. Technically,
> it's
> > several web applications. We implement SSO by caching Shiro native
> sessions
> > via Coherence (we've built a CacheManager, quite similar to Shiro's
> built in
> > EhCacheManager). In order to share the JSESSIONID-cookie over the apps'
> > context roots, it's path is set to '/'. The apps run on WebLogic 10.3.6.
> >
> > The problem: As Shiro sets its JSESSIONID-cookie on '/', so does
> WebLogic.
> > It does this regardless of whether Shiro sets the cookie on '/' or on
> the
> > apps ctx root. This leads to unpredictable behavior, depending on which
> > version of the cookie gets read or written in which order.
> >
> > One solution is to rename Shiro's session cookie. However, for various
> other
> > reasons, we'd rather keep the JSESSIONID name. Preferably, we'd like to
> stop
> > WebLogic from setting it's own session cookie.
> > I though Shiro native sessions was supposed to prevent this? Is this a
> > peculiarity of (this version?) of WebLogic or does it occur on other
> > appservers/servlet containers..?
> >
> > Regards,
> > Lars
> >
> >
> >
> > --
> > View this message in context:
> http://shiro-user.582556.n2.nabble.com/Conflict-with-AppServer-JSESSIONID-tp7578066.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/Conflict-with-AppServer-JSESSIONID-tp7578066p7578091.html
> To unsubscribe from Conflict with AppServer JSESSIONID, click here<http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7578066&code=bGFycy5tLmpvaGFuc3NvbkBnbWFpbC5jb218NzU3ODA2NnwtMjg4MDUwMDM=>
> .
> NAML<http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Conflict-with-AppServer-JSESSIONID-tp7578066p7578093.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Conflict with AppServer JSESSIONID
Posted by Les Hazlewood <lh...@apache.org>.
Hi Lars,
The only time I've ever seen this in other environments is if the
Shiro Filter does not sit 'high' enough in the filter chain.
That is, _something_ before the ShiroFilter is probably calling
request.getSession(). When the ShiroFilter executes, it wraps the
request object to ensure it can intercept request.getSession() calls
to use Shiro's session mechanisms and not the servlet container's.
Something executing before Shiro is probably interacting with the
yet-to-be-wrapped request and starting a container session.
HTH!
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
On Mon, Dec 17, 2012 at 4:30 AM, larsmjoh <la...@gmail.com> wrote:
> Hi,
>
> We have added Shiro to an existing enterprise application. Technically, it's
> several web applications. We implement SSO by caching Shiro native sessions
> via Coherence (we've built a CacheManager, quite similar to Shiro's built in
> EhCacheManager). In order to share the JSESSIONID-cookie over the apps'
> context roots, it's path is set to '/'. The apps run on WebLogic 10.3.6.
>
> The problem: As Shiro sets its JSESSIONID-cookie on '/', so does WebLogic.
> It does this regardless of whether Shiro sets the cookie on '/' or on the
> apps ctx root. This leads to unpredictable behavior, depending on which
> version of the cookie gets read or written in which order.
>
> One solution is to rename Shiro's session cookie. However, for various other
> reasons, we'd rather keep the JSESSIONID name. Preferably, we'd like to stop
> WebLogic from setting it's own session cookie.
> I though Shiro native sessions was supposed to prevent this? Is this a
> peculiarity of (this version?) of WebLogic or does it occur on other
> appservers/servlet containers..?
>
> Regards,
> Lars
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Conflict-with-AppServer-JSESSIONID-tp7578066.html
> Sent from the Shiro User mailing list archive at Nabble.com.