Incompatibility between SP lazy session feature and servlet engine
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
Upon first access to tomcat (and probably most servlet containers) the container attempts to use both cookie and URL-rewrite methods to establish a session. On subsequent requests, cookie-based sessions will be preferred if a cookie is received. When using lazy sessions and when the first request to an app triggers a session startup, a session init URL is generated that is rejected by the SP. For instance:
Rolling back original fix and passing jsessionid back through to rest of SP, but corrected handler mapping to skip both query string and semi-colon delimited path info.
Scott Cantor August 12, 2009 at 12:20 PM
Reopening to apply a better fix.
Scott Cantor October 30, 2007 at 2:44 PM
Ported up to trunk as part of URI decode step.
Scott Cantor October 30, 2007 at 2:18 PM
1.3.1 patched to omit it from getRequestURI result.
Fixed
Pinned fields
Click on the next to a field label to start pinning.
Upon first access to tomcat (and probably most servlet containers) the container attempts to use both
cookie and URL-rewrite methods to establish a session. On subsequent requests, cookie-based
sessions will be preferred if a cookie is received. When using lazy sessions and when the first request
to an app triggers a session startup, a session init URL is generated that is rejected by the SP. For
instance:
https://www.foo.edu/Shibboleth.sso/Shibboleth.SSO/login;jsessionid=asdfasdfsdfsafd?target=foo
The only short-term workaround I could come up with is to use mod-rewrite to hack these URLs back
into a supported form ala:
RewriteRule ^/Shibboleth.sso/Shibboleth.SSO/login;jsessionid.*$ /Shibboleth.sso/Shibboleth.SSO/login
[R,NE]