I'm having an inconvenient dealing with sessions..
I have this:
www.mydomain.com
sub1.mydomain.com
sub2.mydomain.com
sub3.mydomain.com
and when I log into "www", then I change to "sub2" (for example) I
figure out it creates another session :S
why is that??
I need the same session for www, sub1, sub2, sub3, and so on.. ALL in
"mydomain.com"..
what can I do?? is it like that and I have to make a trick?? or is
there a "legal" solution for what I want??
The JSESSIONID cookie is issued by the container, and the cookie domain and path is always that of the web application's domain and context root.
It appears as if you have multiple applications in which case, the JSESSIONID issued by one application will not be recognized by another, due to a change in either the domain or the context root, even if the applications are in the same container.
There are multiple ways to deal with this:
If you are not dealing with a high-value application, and if you can guarantee that no 'rogue' applications will be deployed on the server, you can configure the server to share sessions across applications. Weblogic Server can be configured to do this.
Use a central authentication and session management provider - SSO.
Use TLS/SSL - most servers do not issue a JSESSIONID cookie when communication is over SSL, and instead use SSL itself to store state. You will have mixed results here.
Update:
Glassfish v3 allows you to set the domain for the session cookie. This is done via the session-config element in sun-web.xml. I'm not sure if this is available in v2 or lower versions of Glassfish.
Yes, it is like that because you will have separate session cookie for every different domain. Which web server do you use ? You may implement SSO related solution to share data across the domains.
Look at this tutorial: http://javadude.wordpress.com/2011/05/12/glassfish-3-1-%e2%80%93-clustering-tutorial-part2-sessions/
I summarized all steps for Glassfish 3.1 and session replication
Related
Say I have 2 web applications. One is on a tomcat server and uses java. Abother is written in ASP.NET and is on an IIS server.
I want users to be able to log in on the IIS web application handling authentication, and if through a link they access a page hosted on my tomcat, I want them to be logged in. Both systems can access any/all databases in the background. I also have reverse proxies (F5 devices) at my disposal. The separate systems How could I achieve this?
One solution is to use something called Jespa: http://www.ioplex.com/
Here is another SO question regarding this setup: Tomcat Integrated Windows Authentication across Multiple Domains
My suggestion:
Generate a signature binding with userID and store it somewhere if some one succeeds in loggin in
Add this signature to the url on the IIS web page,and then goes to tomcat pages
Validate this signature which stored before and create session by the userID
I have a legacy application that runs on Spring 1.0 with Acegi security on JBoss 4. Our plan is to migrate one subset of the application to Tomacat 7 and Spring 4. The user will login to the legacy application but if they want to navigate to the subset that is being migrated they would be redirected to the new app.
My question is how would I maintain session information between the two so that the user can seamlessly navigate between the two apps and maintain SSO. There would be no other information exchanged between the two servers. One constraint we have is that we have to make minimal changes to the existing legacy app.
Any help would be much appreciated.
You can't seemlessly maintain session information as far as I can tell.
You might be able to get insanely lucky by configuring JBoss and Tomcat to be clustered using Tomcat's clustering (and assuming that the Tomcat version shipped with JBoss is compatible with the standalone Tomcat you are running), and then enabling SSO on both JBoss and Tomcat, but then you have to be very careful not to place anything in your JBoss session that is not going to be loadable by the standalone Tomcat instance.
You are probably better-off implementing some other solution like using SAML that will likely be less fragile.
You said you didn't want to make too many changes, but if you are willing to get your hands dirty, you could use a shared URL-space between the web applications, use different session id cookies, and then cross-check incoming requests for unauthenticated users by calling-over to the "other" server to fetch their authentication information (which you'll have to make available in the session in some way). I'd advise against storing passwords in the user's session.. instead allow one application to obtain the username of the user in the other application using the session cookie from the first. Trust that the username is accurate and that the user has been correctly authenticated already in the first application, then perform an auto-login into the second.
Whatever you do, it's going to get messy, since your requirements are fairly messy.
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:
<session-descriptor>
<cookie-path>/store</cookie-path >
<cookie-domain>.foo.com</cookie-domain>
</session-descriptor>
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.
As of WebLogic 12c, Oracle confirmed that what we were trying to do is not currently supported. There are also no immediate plans to implement such a feature.
The workaround that we chose to implement was to use mod_rewrite to rewrite the domain of the JSESSIONID cookie at the HTTP server level to be the domain of the request.
I believe such an option should NOT be supported. If it is allowed then nothing prevents hotmail.com from configuring yahoo.com (say) in its configuration file and getting access to yahoo's JSESSIONID value.
If want to store my web application session to different storage, because one every new request user might use different node, is it possible to override default container session storage?
You do not need to overrride anything. It should come with the server you are using. You need to look at "Session replication". In clustering environments, the app server can be configured to replicate session across nodes.
You will need to check documentation of the app server you are using to figure out how this can be enabled.
Please checkout the memcached-session-manager. It stores the session in external memcached server and works for both sticky-session and non-sticky-session(which is your case) scenario.
I want to run my tomcat-instances in a configuration where requests are served to several tomcat-instance via round robin. I don't want to use any internal cluster manager.
As far as I see if every request is served by different tomcats, an unknown sessionId would arrive at a tomcat, so it would be forced to create an new session and overwrite the old sessionId. So for every request a new session would be created. This seems to be a lot of overhead.
Is my view on that things right? Is there a way to disable tomcats sessions management?
Regards,
Michael
Basically you have two choices:
1) Replicate your sessions so they become reachable by any Tomcat node. Solutions: Tomcat Cluster, memcached-session-manager, possibly others.
2) Use a load balancer and implement sticky sessions. First requests will be routed randomly on a round robin basis, but subsequent requests will stick to the same server. Solutions: mod_proxy, hardware traffic managers.
The disadvantage of the first option is that session replication is costly, not very reliable and often requires Serializable-only data to be put in session.
The disadvantage of the second approach is that if you shut down your Tomcat for maintenance, the users will be forced to log in again.
You are incorrectly assuming that "for every request a new session would be created". The new session will be created only if not created before on that same server, or if it was created but already expired.
We usually used Tomcat behind an Apache web server with mod_jk for load balancing the requests across the Tomcat instances.
With sticky sessions a user will only get a session upon the first request and will afterwards always be directed to the Tomcat from where his session originates. So there is no need to replicate sessions across all Tomcats and the requests will be distributed across the Tomcats, too.
Of course, this does not ensure some kind of round-robin which you asked for.
A session will only be created once your code requests the session so if your application doesn't require the session then just simply dont access it. Checkout the section on getSession() in HttpServletRequest
http://download.oracle.com/javaee/5/api/javax/servlet/http/HttpServletRequest.html#getSession(boolean)
I'm not sure if there is a way to replicate the session across different tomcat instances however if you require some user state without session then you can use cookies instead.
EDIT: If you do need to replicate the session you could probably start by reading this tomcat document.
http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html