I am working on this problem for 2 days now and I am hoping that anyone here had a similar problem and a solution for that.
The problem:
It's a Spring MVC (2.5.6.) Web Application, which runs in Tomcat 6.
When the start page is requested it redirects the customer to a JSP Page (by using HTML's meta refresh tags) which loads it's content with a lot of Ajax requests (Framework: Prototype). The problem is that Tomcat creates a new session for every AJAX requests (about 67 sessions).
My first thought was that the Session Cookie is stored after the start page is loaded and the Ajax requests forces the Tomcat to create a new session. My approach was to create the session cookie by hand, but this did not make any difference.
The funny thing is that it works in some other tomcat instances, but not in the desired environment for the integration tests. In my opinion it's a Tomcat configuration issue.
After further investigation with Firebug, I found out that Tomcat creates a new Session for every request even if the right JSESSIONID is transfered to it (50B5EA0BCFE811C744CE9C1F9EDE0097):
Request Header 1:
Cookie JSESSIONID=F3206CBF2C961E125821FF22FA31A02D
Response Header 1:
Set-Cookie JSESSIONID=49E000B4D6880F4F94531AB9C78DB667; Path=/JOCA-Music-Portal JSESSIONID=50B5EA0BCFE811C744CE9C1F9EDE0097; Path=/JOCA-Music-Portal
Request Header 2:
Cookie JSESSIONID=50B5EA0BCFE811C744CE9C1F9EDE0097
Response Header 2:
Set-Cookie JSESSIONID=DCCA2D1B98D11223A6B8855800276E27; Path=/JOCA-Music-Portal
UPDATE: Further investigation isolated the problem to the Tomcat Realm configuration. We use a JDBC Realm for login. When the login is deativated, only one Session is created.
If it's activated, Tomcat creates invalidated/expired sessions, that's why a new session is created with each request. But why does Tomcat behave like this?
I'm really desperate, so any thought/hint/solution is well appreciated.
Thank you very much
You can try to analyze the HTTP traffic between your client and your server. Make sure the Cookie header is set correctly in the request and the response.
If using Firefox, you can try to debug with Firebug.
We recently ran into the same issue with an app we were developing. Come to find out, the issue is that Tomcat was modified to help prevent session fixation attacks. By default, a new session id is created on authentication. This started with 6.0.21. Check out the context configuration option 'changeSessionIdOnAuthentication' (tomcat bug/issue is https://issues.apache.org/bugzilla/show_bug.cgi?id=45255).
We ran into the same problem, but when using custom EXTERNALSSO authentication. The solution was to explicitly turn it off in the constructor of our class that inherits from org.apache.catalina.authenticator.AuthenticatorBase:
super.setChangeSessionIdOnAuthentication(false);
Related
I'm trying to create a Spring Boot backend which is able to make requests to this url. When requesting this url with a fresh browser window, aprox. 50 requests are made.
I managed to saved the cookies from the first request to the above url, but how do I approach following the follow-up requests from the browser, which are often triggered by javascript code, to set all the cookies? Is there an easy way?
My approach is to request all the urls which set cookies manually using my network recording. Is there a better, automatic way? Thanks so much for your help.
You could make the request with Selenium in headless mode to achieve what you need with very little effort.
To solve cookies related vulnerabilities, I have written wrapper on request and response in one my filter.
In request wrapper I overwrite cookie using following code in getSession method(overridden)
HttpSession session = getHttpServletRequest().getSession(false);
String value="JSESSIONID=" + session.getId() +"; Path="+getHttpServletRequest().getContextPath()+"/";
((HttpServletResponse)response).setHeader("Set-Cookie",value);
In response filter I have overridden addCookie and addHeader methods to do the same.
The above code is working fine for tomcat and jboss, but it is giving issue on websphere 8.5.
For websphere 8.5 it is giving session null in the getSession method getHttpServletRequest().getSession(false)
When I inspect network traffic from browsers developer tools then for websphere I observed multiple cookies are getting added on response (one which is we added and other added by server), to avoid this I have done setting in websphere session management to disable the cookies. This solves the multiple cookies problem but null session problem still persists.
How to solve this problem?
Thanks
You should not have an explicit "false" parameter in your code, you should pass what your wrapper was passed. You are likely breaking callers who pass true and are therefore not establishing NEW sessions correctly.
You will also likely break session affinity, because you aren't copying the cloneID that follows the session ID.
Why not just set the cookie path in the configuration if that's all you intend to change?
Cookies support - Problem?
Original Issue/Background:
We have API based on servlet / JSON running in Openshift, the web server used in openshift is Tomcat.
We store information to httpsession and everything works fine when used directly against openshift / tomcat (POST / GET). But when we configured apigee against existing methods the session is lost. Stuff is stored correctly in the session in server side, but when second request comes from apigee into the tomcat the session is "lost"
Piece of java code to get the session is plain httpsession.getRequest(). As said this works fine when using backend directly. Is there some additional steps (cookies etc) needed to maintain the session when requests are used through apigee?
Update Findings;
With short debug an traffic monitoring the reason of the error in apigee is confirmed to be that it does not pass JSessionId to requests. This means that cookies support should be enabled somehow in the API proxy settings / Configuration.
Anyone have an idea where or if this can be resolved?
First off, cookies aren't part of a proper RESTful payload -- if you grabbed the headers you could store them with an access_token as part of the generate token policies.
That aside, you should be able to pass the cookies back to the requesting App and then let the app pass them back to the API -- my jokeindex API lets you do this.
Make sure you don't have any AssignMessage policies in the flow that are stripping out the headers accidentally -- something like this:
<Set>
<Headers />
</Set>
as that will remove ALL headers. Also, you can look at the Trace tool in Apigee to check each policy step along the way to see if you're stripping the Cookie: header from the requesting payload.
When you have your resource on address "http://yourdomain.com/somewhere/", and you redirect to that resource from apigee API, for instance by url: http://yourapi.apigee.net/v0/myresource" what you get back from your server is cookie for /somewhere/ not v0/resource/somewhere, so basically when browser gets cookie back, it does not put it into correct place and discards it. At least that was/is my case.
You should ping #bissell about this but I did find this article that might be helpful:
http://community.apigee.com/groups/learn-create-and-manage-apis/some-basic-questions-new
Also, you might be able to fix your issue by adding an "extract variable" policy to the request that captures the JSessionId and then adding an "assign message" policy to add it back to the request.
You can assign policies from API Platform>Dashboard>API Proxies>YOUR API>Develop
I'm using Spring MVC, MySql and Tomcat 7.
Currently the application I'm developing can be accessed by 2 URLs namely IP:PORT/APP and www.app.com.
When accessing via www.app.com I see a session being created for every page/link that I open but it doesn't happen when I access via IP:PORT/APP.
I have a check for logged-in user in every page and due to too many sessions that check is failing and I'm being re-directed to my login page even after logging in.
Also when opening the www.app.com index page I see a jsessionid on the address bar and not when i open it via IP.
Any help/guidance is appreciated.
It seems that when you are accessing the page via domain name (www.app.com), cookie support is not found and hence the url rewriting is being done (i.e. appending jsessionid at the end of the url). But this is not observed while accessing the same page via IP Address (IP:PORT/APP), meaning cookie support is enabled at this time.
You can check if you have enabled some security settings that is not allowing cookies.
Further to this, it seems that even url rewriting is not helping as sessions are being created for every request.
You can use some HTTP Interceptors to analyze the request being sent and response being received in each case. You can use Developer Tool in Chrome to inspect this. Load you page in Google Chrome, Right Click on Page and Click 'Inspect Element'. Open the 'Network' tab. Reload the page. You can now inspect the HTTP Request Headers sent and Response Headers received for each request. Analyze the difference between the request using IP Address and requests using Domain Name.
Also, share the architecture of the application and the environment where you are testing the application.
I have developed a simple web-app with 2 servlets A and B.
I have a few doubts related to session management for the web-app by Tomcat.
NOTE - I have disabled cookies in my web-browser (Chrome) while accessing the web-app.
1.) When the web-app is first hit, Servlet A gets invoked. Servlet A accesses the session from the request and does a simple sysout of the session hashcode. It then does a sendRedirect to servlet B.
[According to my understanding, since this is the first request, Tomcat will send a cookie containing the new session ID back to the browser. However, since we have not "encoded" the redirect URL using HttpResponse.encodeRedirectURL(), the redirect URL will not contain the session ID appended to it. Please correct me if I am wrong here.]
2.) Since cookies are disabled in my browser, it'll ignore the session ID sent back in the cookie and issue a new request to the redirect URL (which also does not have the session ID appended to it).
3.) The new request causes servlet B to be invoked, whoch also accesses the request session and does a sysout of the session hashcode.
What perplexes me is that both Servlets A and B output the same session hashcode, which means that they get the same session from both requests.
How does the second request from the browser map to the same session as before, even though no session ID has been sent ?
Thanks !
There are only 2 ways to pass sessions between requests: Cookie and URL rewrite. If you don't see the session ID in the URL, it must be cookies.
Are you sure the cookie is disabled? It should be easy to see from a HTTP header trace.
Are you certain you've disabled "in memory" cookies? Often browsers will let you disable persistent cookies which are saved to disk, but they'll still allow the transient in memory cookies which only stay resident during a browser session.
I recommend Wireshark for analyzing the HTTP stream. That way you can see the cookies that are sent and received by your browser.
This is strange.
When I tested the application yesterday, it was exhibiting a behaviour similar to what I have described. However, as I test the application now, it behaves perfectly, as I expect it to.
The cause could probably be that I did not restart my browser session after disabling cookies.
Will let you guys know if I experience the same behaviour again.
Thanks for your time guys !