0

It is possible as shown here to use configure Tomcat (or I guess any other Servlet 3.5 compliant container) to use the same JSESSIONID values for a session of a browser using multiple Java applications (e.g. on different tabs) on the same container.

However as explained here the session objects will be different - only the JSESSIONID value will be the same:

SRV.7.3 Session Scope

HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container.

Given that HttpSession objects (and thus the session scope memory areas) will be different on the server side among the different applications, the only way this mechanism can serve to pass information among the different applications would be to either:

(a) store some information in the JSESSIONID value itself

or

(b) use the common JSESSIONID value to perform lookups on a back-end database or access in a server-to-server way some REST API and access shared information that resides there on the basis of the common JSESSIONID.

Option (a) is not possible as the JSESSIONID value is created by the container so there is no way to engrave additional information on it.

Is my above perception correct and what are some use cases for which you would like a set of applications deployed in the same servlet container to share the session identifiers ?

For instance, I guess option (b) could allow some simplified Single Sign On implementation among the applications sharing the same JSESSIONID (and to the extent they are all delpoyed in the same Servlet container).

Community
  • 1
  • 1
Marcus Junius Brutus
  • 26,087
  • 41
  • 189
  • 331
  • here's a case - http://stackoverflow.com/questions/33247677/my-web-application-stop-working-after-jsessionid-appear-in-url/33248435#33248435 – ZhongYu Nov 29 '16 at 21:32

1 Answers1

0

You could use the JSESSION id as a key on a database that is used by many apps. E.g. for auditing purposes.

Andres
  • 10,561
  • 4
  • 45
  • 63
  • Yes, I see that. But why would I want to mess up with the default session identifier and not choose to instead set up a custom cookie with paths corresponding to all the applications that need to share information? This way I would have a cookie used explicitly for this auditing (or other) purpose and leave the default session identifier alone. – Marcus Junius Brutus Nov 25 '16 at 16:54
  • Session is a cookie. Why create another one? Also, you're just reading the session value, not messing with it. – Andres Nov 25 '16 at 16:55