Hi Emmanuel!

Good to hear from you.

This depends on how Nexus is using Shiro - if Nexus uses Shiro as the
native session manager (e.g. for session clustering and
customization), this completely bypasses the servlet container's
session mechanisms on purpose.  Shiro implements the Servlet 2.5
specification (for Sessions), so there is no need to talk to the
servlet container for Sessions.

If Nexus uses Shiro's native sessions, and someone tries to modify the
servlet container's session-related configuration, then of course
Shiro has no knowledge of this - it would be a Tomcat-specific
feature.  This means that Tomcat (or anything else in front of Shiro,
like a load balancer) should 1) remove any modifications from the
JSESSIONID before the application (and thus Shiro) reads it and 2) add
to the JSESSIONID cookie value after Shiro is done writing it.

This is a common technique performed by load balancers - the key is
that the application should not see the effects of these changes in
the header - they should be stripped before the app receives the
request and added after the application responds.

So it sounds like Henry is using a Tomcat-specific feature that
assumes Tomcat is performing Session management.

Isn't there a way to use a different custom header instead of
interfering with the JSESSIONID?

If not, maybe a Shiro Filter can be used to support the desired
behavior? (not sure entirely about this - it's just a hunch).

HTH!

Best,
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282


On Mon, Jun 24, 2013 at 8:33 AM, Emmanuel Lécharny <[email protected]> wrote:
> Hi guys,
>
> a fellow Apache committer (Henry Gomez) told me that he has some issues
> with Shiro used in Nexus : Shiro rewrite the undrlying Tomcat
> JSessionID, losing the informations it contains.
>
> Cf https://issues.sonatype.org/browse/NEXUS-5756
>
> It sounds a bit strange.
>
> Do you have any idea about what can be the pb ?
>
> Many thanks !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

Reply via email to