We have a weblogic application that needs to support being served from multiple domains (e.g. "foo.com" and "bar.com"). Once a user initiates a session on one of these domains they can visit to subdomains off that primary domain (e.g. "a.foo.com", "b.foo.com") and share that session across all of these subdomains. If a user jumps from "foo.com" to "bar.com", they will lose their session, which is fine.
We were able to successfully implement this on JBoss/Tomcat by customizing a 'Valve' to rewrite the session cookie to always be at the top level domain for the serverName that is being requested (i.e. request.getServerName()).
However, we are currently in the process of migrating our application from JBoss to Weblogic and are trying to figure out how to support the same requirement. We have found that weblogic does allow for sharing sessions across multiple subdomains of a single domain by setting the 'cookie-domain' property within the weblogic.xml:
However, we haven't figured out how to configure support for multiple domains (i.e. both foo.com and bar.com). From what we can tell, the weblogic.xml file doesn't support this.
If we only configure one of the domains in the weblogic.xml, sessions do not work properly for the domain that is not configured (i.e. every request leads to a new session).
Any ideas on how we can support sessions across different domains for a single web-app on weblogic?
We are running on Weblogic 12c.
If we do that, then the session won''t be shared across the subdomains, right?
For example if I first start my session on a.foo.com, the session cookie will be tied to a.foo.com, and if I jump over to b.foo.com, I will get a new session cookie and a new session. That is why we specified the cookie-domain originally.
Thats not true. When you access foo.com you get the cookie. If you change to b.foo.com since you will have a cookie with the same name as expected by your webapp it will continue to use it.
you can see this behaviour when accessing two wls consoles from the same browser in two tabs. They will keep overriding each other. But in your case you can exploit this to work for your benefit as its effectively the same server and webapp handling the request hence the cookie will be shared no matter the url.
In our case the user can start their session on either the top level domain or any of the subdomains.
For example, the user could first hit http://a.foo.com and login. If they then navigate to another subdomain (i.e. http://www.foo.com) their session cookie is not passed back and therefore they lose their session. This is the reason we had introduced the cookie-domain setting.
I have verified that I do indeed lose my session in the scenario outlined above.
Does that make sense?
I am assuming you are able to access foo.com/console and a.foo.com/console and b.foo.com/console
if so login to wls console using any of the urls and then criss-cross between the other urls and check if you still are logged in to the wls console. If so then you are sharing the cookie and the session.
now access bar.com/console are you asked to relogin or do you see the same session continue ? Make sure you are checking only wls admin console url and not your application.
You can also enable httpheader debug on the browser end to check the cookie details and http header being passed on. if you are using a wlproxy you can enable debug there and also track the session to confirm the behaviour.
Thanks for your reply.
I went through the scenario you described above. If I first go to the console through a.foo.com, the cookie is issue to the a.foo.com domain. As soon as i change the URL to foo.com, I am logged out as the a.foo.com cookie is no longer submitted back to weblogic.
This is the same issue we are seeing if we don't set the cookie-domain on our app. However, even if we set this - we still don't know how to support both *.foo.com and *.bar.com.
The documentation for cookie-domain session-descriptor attribute says -
Specifies the domain for which the cookie is valid. For example, setting
The domain name must have at least two components. Setting a name to
If not set, this attribute defaults to the server that issued the cookie.
For more information, see
I was suggesting you to unset the cookie-domain that you have set, and from my recollection wls admin console webapp does not set this to any value.
If you enable httpheaders debug from browser, wonder if you will be able to see the cookie-domain value being set, and what its setting to when left blank.
As mentioned here http://www.javasanity.org/node/18 and https://sacrephill.wordpress.com/tag/multiple-session-cookies/ try setting a cookie-name attribute too.
Wondering if configuring virtual hosts is the solution for your issue http://docs.oracle.com/cd/E24329_01/web.1211/e21049/configurewebapp.htm (though I havent tried it myself)
For the previous message (testing with the console), I did not have the cookie-domain setting enable. That test was with standard out of the box settings.
We've tried the cookie-name setting, but that still doesn't fix the fact that we cannot jump from a.foo.com to foo.com (and keep the same session). If we set the cookie-domain to foo.com, we still have issues with bar.com domains.
Will look into the links you sent.