I have several tomcat instances running in physically independent machines.
I want to configure the tomcat to share sessions between this instances.
I have tried to configure org.apache.catalina.session.PersistentManager from http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html. But I only see the session file when I shutdown the tomcat instances and I don't know if the instances are sharing this session. I think not. Because It doesn't make sense if tomcat writes down the session only on shutdown.
The other thing that I found is the cluster-howto but I can't do that couse the machines can't see eachother. They only shares a storage path to use.
Other thing that I think I can do is to implement a manager but it seems a litle bit tricky.
I have to add that I am using tomcat for deploying grails war files and I am using the grails session. I thing it has something to do with Spring
So, the question is: What is the best thing you think I can do to accomplish more effectibly the task? Or maybe I am missing something? Can you give me any pointer?
You have the F5 Big IP doing the load balancing in front of the tomcat servers, so it will handle the sessionID for you by sending you back to the correct Tomcat server. Use the sticky-round-robin algorithm.
As per the usecase in your comments -
What I am trying to do is to save some
data in session, then redirect to a
login server, who in a success
scenario it redirects to my servers.
And my concern is what happend if the
load balancer redirects the request to
the server that doesn't previously
saved the needed data in session.
Maybe sticky session is what I need.
So: can I configure sticky session in
a non tomcat-cluster enviromnent?
At the successful login - you redirect back first to the BigIP. It will pick up the sessionID from the browser. It will send you to the correct Tomcat and you should be able to retrieve the session data.
If not, looks like you need to store the "sessionID" itself against some "user Id" in a database but thats a bad design. I think the former should work
Related
I have a webapp deployed successfully in Jetty webserver.
The webserver responds to requests fine.
When I access the app it renders the home page.
Recently I noticed that when I don't use the app for certain period of time it breaks somehow. The period is somewhere around 2/3 weeks.
When I access the webapp after 2/3 weeks of idle I receive this output.
If I try to access any other link, i.e. the login page (/login.faces) I receive:
Problem accessing /error/not-found.faces. Reason:
/error/not-found.xhtml Not Found in ExternalContext as a Resource
which normally used to work before idling.
If I restart the webserver everything returns to normal and works fine. There are scheduled tasks set which make the app interact every day with database. (There is a scheduled task for fetching currency rates via webservice).
Therefore, my question is what would be the cause which breaks the site and makes it unavailable after idling? Is this a webserver (jetty) issue? Am I missing any setting which is crucial?
FYI, the project structure is: Java with Spring, Hibernate, JSF (PrimeFaces) and Jetty
This occurred due to permissions in CentOS.
If anyone faces the same issue make sure to check the logs have appropriate permissions to read and write
I have a tomcat 8 server in which i have two web app. I want to give access to both application by authenticating once an user.
I did it by setting sessionCookiePath="/" in catalina/conf/context.xml like this :
<Context useHttpOnly="false" sessionCookiePath="/">
Now the problem i am facing is tomcat is not changing session ID anymore. I got a warning message.
Warn org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy - your servlet container did not change the session id when a new session was created
On the link, it is said that tomcat is taking care of that by default.
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
How can i fix it ?
Thanks
Yes, this is expected behaviour. The documentation hints at this but
does not make it explicitly clear.
Setting sessionCookiePath="/" is treated as a special case to support
portlet implementations. Once one web application obtains a session all
subsequent sessions for any web application also configured with
sessionCookiePath="/" will always get the same session ID. This holds
even if the session is invalidated and a new one created.
If a set of web application operates in this mode, changing the session
ID is a lot harder. You'd have to write a custom Tomcat component to do
it for you and even then I'm not sure that you can guarantee a smooth
change over.
I have a web application that does most of its logged in user dependent actions based on a persistent cookie that maps to a database record such that each ajax POST does not need or want a tomcat session.
In a very small number of ajax requests, I have a small amount of servlet session data to save for the logged in user, and I want the session to persist for a very long time (as long as he has the browser open), even if there is a long period of inactivity.
Now, my understanding is that there are sticky sessions or replicated sessions for a tomcat cluster, your choice. In most cases, I would want my load balancer to send the traffic to the least loaded tomcat instance, and the servlet never gets or creates a session. In a very few cases, I need a session and access to the small amount of session data.
Also, I am using apache mod-proxy. Does this constrain the choice?
If I were to choose a sticky session load balancing, then the vast majority of my ajax requests that don't need to be sticky would go to the same tomcat server anyway. Yet some have said that sticky sessions give better performance if you are not worried about failover.
Can someone tell me what the right choice is in my case?
One idea that I had was in that whenever I create a session in tomcat, I also create a MYSESSIONID cookie for just a particular servlet (path) set to the same value as the tomcat sessionid. Then, in all of my very few servlet requests that require access to the session data, I go thru this one routing servlet, and the load balancer can create a sticky session tied to MYSESSIONID cookie. Is this a good solution?
Andy
A session is global to a web app. It isn't tied to a particular servlet in the webapp. Your routing servlet doesn't make much sense.
If you're not worried about failover, then sticky sessions are easier. If you need clustering, this probably means that you have an awful lot of concurrent users. So, in average, the load should be similar on all the servers anyway.
On the other hand, if you have very few data in the session, and your application modifies it rarely, replicating the session should not cost much. You would have failover as an added advantage, and the load balancer could use a pure round-robin algorithm, making sure that each server gets the same number of requests as the other ones.
I have an application that uses coldfusion's session management (instead of the J2EE) session management.
We have one client, who has recently switched their company's traffic to us to come viaa proxy server in their network.
So, to our Coldfusion server, it appears that all traffic is coming from this one IP Address, for all of the accounts of this one company..
Of the session variables, Part 1 is kept in a cflock, and Part 2 is kept in editable session variables. I may be misundestanding, but we have done it this way as we modify some values as needed throughout the application's usage.
We are now running into an issue of this client having their session variables mixed up (?). We have one case where we set a timestamp.. and when it comes time to look it up, it's empty. From the looks of it this is happening because of another user on the same token.
My initial thoughts are to look into modifying our existing session management to somehow generate a unique cftoken/cfid, or to start using jsession_ID, if this solves the problem at all.
I have done some basic research on this issue and couldn't find anything similar, so I thought I'd ask here.
Thanks!
I've run into similar problems on and off for years.
JSession cookies seem to help (no hard data on that) but one solution that I've implemented repoeatedly is using no-cache and cache expiry headers on every page.
http://www.bpurcell.org/blog/index.cfm?entry=1075&mode=entry gives some specifics on how to implement this.
In extreme cases, we've been forced to pass the token and cfid in the links/forms, but that is a PITA to implement, so I'd try the cache expiry/prevention soluiton first.
As far as I know, there are no "cons" in using J2EE session variables, unless you really need session to be active after user closes the browser. I think you should try and see how application behaves with it and see if that saves you trouble of refactoring.
To be sure that you are using all other settings try this:
<cfdump var="#APPLICATION.GetApplicationSettings()#" label="Application settings" />
If you have sessionmanagement and client cookies turned on, everything is fine, so try j2ee session variables.
I have a Spring 2.5.6/Flex application setup and running with Spring Security 2.0.4. Recently a load balancer (A Foundry ServerIron 4g http://www.foundrynet.com/products/a...ems/si-4g.html) was put into place and now I am getting cross domain errors. Basically the load balancer is firing off a request to myloadbalancer.abc.com and myrealserver1.abc.com is being returned as the domain name. Spring security is forwarding the request to the real server somehow. How can I get around this?
Also the ConcurrentSessionFilter is no longer working. The application is set up to disable concurrent logons, but this functionality stopped after the application was put behind the load balancer. I believe there are multiple Oracle Application Servers being clustered together as well. I have never dealt with clustering or load balancers before and I wasn't aware that the software had to be written differently in certain areas.
These sound like separate issues to me, but I need help for both.
Concerning your second problem:
If the ConcurrentSessionFilter stopped working (i.e. does not prevent concurrent sessions anymore), that could be due to clustered application containers with sticky sessions.
In such a setup, each of the cluster's nodes works independently and doesn't share state with other nodes. Instead, the load balancer makes sure that existing sessions will always be served by the same node.
Now Spring Security's ConcurrentSessionController works by mapping sessions to principals. The controller itself relies on the HttpSessionEventPublisher sending ApplicationEvents on start and termination of user sessions.
Everything is will work fine if someone intending to open more than one session ends up on the same node he already has a session opened. HttpSessionEventPublisher informs the concurrent session mechanism of the session's creation and authentication will fail because there is already a session associated with this user. On a different node however, there is no session for that user yet, so ConcurrentSessionController does not complain and login succeeds.
Fortunately, solving the problem should be easy: Implement your own SessionRegistry and use a shared data store for all nodes (e.g. the application's database).