I'm trying to handle some cookies with Spring.
For that I'm easily geting them like this: request.getCookies();
Now I noticed that Spring shows me only 6 of 10 cookies. In Firefox I see way more.
If I run theCookies = document.cookie.split(';'); in the browser console, I get only 5 cookies, but the one I'm looking for does contain in the list but not in the list from Spring.
Related
I have 2 spring apps, I send requests from the First app to the second one with unirest. Something like below, as seen I am using basic auth. So far it works. I suddenly got this thought, will this create a session on each request? If so can I immediately end the session after the response is sent? I am not much willing to change the current implementation.
HttpRequest jsonResponse = Unirest.get(beeUrl+"/getPresentById/"+memId+"/"+role).basicAuth(bid.getPvalue(), bpwd.getPvalue()).header("Content-Type", "application/json");
We have a Node.js application that invokes a Spring controller. For a PoC purpose, I am creating the cookie in the Spring controller before returning the JSON response to the Node.js application.
Cookie cookie = new Cookie("myCookie", "myCookieValue");
response.addCookie(cookie);
I had my Firebug console open to see if the cookies created in server side are visible but, unfortunately i did not see them.
Also, on the 2nd submit, i tried reading the cookies using request.getCookies() but this is also giving me NULL.
Are the cookies not being received by the browser because it is a
Ajax/JSON request-response ?
Merged with Google Chrome cache problem.
all,
I am building a service using Spring 3.0 and i am using spring security for authorization/authentication. I have correctly setup the Apache/Tomcat ajp setup to use SSL and send appropriate cache headers for all static resources (1 week) which Firefox seems to interpret correctly (i can tell from firebug that it doesn't fetch these resources each time). On the other hand, Google chrome will only fetch the static resources (.css, .js) from cache for the login page. For all the rest of the pages/requests it sends a GET to the server and then the server replys with a 304 Not Modified response. If i disable SSL caching works normally but only for the same jsessionid that Spring security uses. I have checked the browsers cache and i actually saw that for plain HTTP resources are getting cached but are bound to a specific jsessionid i.e.
http://localhost/myservice/resources/jquery/js/jquery-ui-1.8.9.custom.min.js;jsessionid=3B15E163E138CCE8839306FF5A924D87
I am confused...can anyone help?
Thanks
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);
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 !