Wildfly 10: cannot share the same JSessionID between two different applications

[dk_efiport]

I deployed two WARs which should share the same JSessionID cookie. This is because I use the JSessionID to implement a Single-Sign-On mechanism by persisting the ID in the database with user information. The applications then know who is the user by searching for the JSessionID in the database.

In old JBoss environment it worked without problems.

Now after migration to WF10 I cannot get it working.

I tried to set the path of the cookie-config to / by adding the following to jboss-web.xml of both applications:

	<session-config>
	<cookie-config>
	<path>/</path>
	</cookie-config>
	</session-config>

This creates a JSESSIONID cookie with path "/" which is fine.

But if I make a request to the second application, a new JSESSIONID value is created and the cookie value is being replaced (also with path "/").

if I make a request to the first application, a new JSESSIONID value is created and the cookie value is being replaced (also with path "/").

Can anybody explain to me how to fix this?

[mchoma]

You can share session between wars in ear

Web (Undertow) Reference Guide - WildFly 10 - Project Documentation Editor

[dk_efiport]

I will give it a try, but for me it would be sufficient or even better to share just the JSessionID and not to share the session itself.

In JBoss 4 (from where I have to migrate the applications) both applications were using the same JSessionID. They should not have access to data of the other application's session. But I am not sure if this is possible in WF10.

Another issue with the EAR configuration you suggested seems to be that every object in the session has to be serializable. So without code changes the application currently doesn't work.

[pferraro]

I will give it a try, but for me it would be sufficient or even better to share just the JSessionID and not to share the session itself.

I don't fully understand your use case.  If your sessions are specific to their respective web applications, what need would you have to reuse session IDs?

Another issue with the EAR configuration you suggested seems to be that every object in the session has to be serializable. So without code changes the application currently doesn't work.

The distributed session manager only requires that session attributes are serializable if the backing Infinispan cache configuration requires it.  This has been the case since WF10.  See: WFLY-5502 Don't require marshallable session attributes if the cache … · wildfly/wildfly@b254e50 · GitHub