I have the web application. I deploy it into jetty container.
After browser restart it looses jsession id although session alive on server and redirect me to login page.
In browser I see following cookies:
How to know current jsessionId cookie type ?
Can I change cookie type to resolve my issue?
How to change jsessionId cookie type ?
Which type would be proper at this case ?
Your session is not deleted until its expire time on the server side.
However, your "browsing session" ends when you restart your browser. Therefore your browser deletes all session based cookies, including the one grabbed from your website. As as result, you lose your old session and forced to start new session.
Check this out:
What is the best way to implement "remember me" for a website?
The cookie that identifies your session is JSESSIONID. See that expires attribute for that cookie is Session which means that the browser will forget it when you close it. You need to make the server set expires attribute for the cookie, that is login response should contain header similar to:
Set-Cookie: JSESSIONID=<id>; expires=Tuesday, 05-Nov-2004 08:30:09 GMT; ...
Read documentation for your authentication library to find out how to do that.
Here's the scenario:
Login as User A - Sets a JSESSIONID cookie
Logout
Login as User B - Attempts to overwrite the JSESSIONID in IE with the new one
Subsequent calls to the server no longer have a JSESSIONID cookie sent in the headers
Here is what the traffic looks like:
Here is what it looks like when the 2nd login attempts to "overwrite" the JSESSIONID cookie
You can see here that the "old" JSESSIONID ("DSE6...") was Sent to the server, but that the "new" JSESSIONID ("CD26...") was Received.
A few other details:
Tomcat 7.x is on the server-side
Using httpOnly, secure cookies
This is ONLY an issue in IE; everything works fine in Chrome and FF
So the question is: why is IE forgetting the JSESSIONID when the server attempts to overwrite it?
I have a web application in Tomcat 7 which keeps user information in session as a DTO object. I also have Spring security enabled for my project which automatically redirects a user to a login page if the user does not have a session.
If I log in to my application once and then I restart Tomcat in Eclipse what happens is that my session gets flushed out but the cookie does not go.
What this means is that after server restart there is no UserDto in session but a valid JSESSIONID remains with browser. Thus spring security still thinks that the user is logged in when in fact he's not.
Why is this happening? (I have check the type of JSESSIONID cookie by viewing page info in Firefox it says - Expire: At end of session. Thus it should ideally expire at server restart or shouldn't it?)
Edit: Though Firefox says Expire: At end of session the cookie is still there if I close and restart Firefox.
From Servlet 3.0 to add expire date to a cookie you can add cookie-config to your web.xml file
<session-config>
<session-timeout>30</session-timeout>
<cookie-config>
<max-age>1800</max-age>
</cookie-config>
</session-config>
The cookie is held in the browser - when the server restarts, but the browser continues to run, it will hold onto the cookie and present this to the server on next request.
Now on the server side, you have multiple options: You can configure tomcat's SessionManager to persist on disk and read the content upon restart - this is an option that also is used to distribute sessions between multiple tomcats in a cluster: When the session is serialized to disk, any server can continue the session by "just" deserializing it. There's some cost implied (as you constantly need to serialize sessions)
Currently I can't give you more concrete hints than this - but if you look it up and understand the difference between where the cookie is stored, why it doesn't change on server restart and that you'll have to look up tomcat documentation of the session manager, you'll hopefully manage to figure it out.
Tomcat will generate a JSESSIONID automatically if you have used session in you web project.
If the session id changed then the JSESSIONID will changed corresponds. Because
the JSESSIONID indicates the seesion ID of the WEB project.
It will expire when the server stop(in default it will expire within 30 minutes), but the cookie cannot delete automatically.
JSESSIONID can configs in server.xml file of tomcat.
While you log in succesfully, SpringSecurity stores a cookie in your browser.
When the browser sends a request, SpringSecurity checks what's in the cookie. If SpringSecurity finds the value it stored before, it thinks you have logged in, so SpringSecurity won't redirect to the login page.
Is it possible to keep the same jsessionid on 2 differents url in the same domain?
Example :
I'm on the home page of my site (http://MyProject.com). When I click on a button, I'm redirected to "http://param.MyProject.com". At the moment, the browser doesn't send the current jsessionid and the server creates a new one but I would like to keep the same.
The consequence is that when the url changes from MyProject.com to param.MyProject.com, I loose my HttpSession and I'm logged out.
I use tomcat 7 and Chrome or Firefox.
Thanks for your answers.
It really depends on the "domain name" set for the Cookie.
A Cookie set for www.myproject.com will not work with param.myproject.com, but if the cookie is set for myproject.com, it will work for myproject.com and all sub-domains of myproject.com
You can configure the cookie domain for tomcat by modifying META-INF/context.xml as below:
<Context sessionCookiePath="/" sessionCookieDomain=".myproject.com" />
I have this big issue. My current session is gone every time I made a new request to Server.
I have checked in a lot of places. I can't find what's the problem. I also have included
session-config in web.xml both in tomcat and application. I also enabled to accept cookies to my browsers. Tested in every browser. It's not working.
I am just developing a simple java ee applcation using JSP/Servlet. I am facing the problem only after I have deployed to tomcat in server machine.
One possible cause for this is having a "naked" host name (i.e. one without a domain part). That's fairly common if you're working in an Intranet.
The problem is that almost all browsers cookies will not accept cookies for hostnames without a domain name. That's done in order to prevent evilsite.com from setting a Cookie for com (which would be bad, as it would be the ultimate tracking cookie).
So if you access your applicaton via http://examplehost/ it won't accept any cookie, while for http://examplehost.localdomain/ it will accept (and return) the cookie just fine.
The nasty thing about that is that the server can't distinguish between "the browser got the cookie and ignored it" and "the browser never got the cookie". So each single access will look like a completely new sesson to the server.
After years, I never posted the answer back here. At that time I was busy and forgot about this question. But, today I am looking for a solution in Stackoverflow as usual and saw this notification mentioning I am getting points from this Question. Seems like other developers are facing the same issue. So, I tried to recall how I solved the issue. And yes, I solved by manually put back the session id to track/maintain the session id.
Please see the code that I manually put back jsessionid inside the servlet.
HttpSession session = request.getSession();
if (request.getParameter("JSESSIONID") != null) {
Cookie userCookie = new Cookie("JSESSIONID", request.getParameter("JSESSIONID"));
response.addCookie(userCookie);
} else {
String sessionId = session.getId();
Cookie userCookie = new Cookie("JSESSIONID", sessionId);
response.addCookie(userCookie);
}
First check if the webapp's context.xml does not have cookies="false" configured.
Further it's good to know that cookies are domain, port and contextpath dependent. If the links in the page points to a different domain, port and/or contextpath as opposed to the current request URL (the one you see in the browser's address bar), then the cookie won't be passed through which will cause that the session cannot be identified anymore and thus you will get a new one from the servletcontainer.
If that is not the cause, then check if you aren't doing a redirect on every request using HttpServletResponse.sendRedirect() for some reason. If you do this already on the very first request, then the cookie will get lost. You'll need to replace
response.sendRedirect(url);
by
response.sendRedirect(response.encodeRedirectURL(url));
In Your properties
server.session.cookie.http-only=true
server.session.cookie.secure=true
Remove these settings, it will retain your session id cookie, which is being reset with every request.
I experienced a stale https session cookie (my ad-hoc term) problem, due to a secure flag.
I had this problem when switching between http and https. The cookie stored by https session was never overwritten by http session. It remained in FireFox memory for eternity. It was visible in FireFox Tools / Options / Privacy / Delete single cookies where in Send for field it was Only for secure connections. Clearing this single cookie or all cookies is a workaround.
I was debugging the problem with wget, and I noticed such a header:
Set-Cookie: JSESSIONID=547ddffae0e5c0e2d1d3ef21906f; Path=/myapp; Secure; HttpOnly
The word secure appears only in https connections and creates this stale cookie. It's a SecureFlag (see OWASP). There are ways to disable this flag on server side, which seems like a permanent solution, but maybe not safe.
Or is it a browser bug, that the cookie is not overwritten?
Try adding the Live Http Headers plugin to firefox, and make sure the session cookie is indeed being passed to the browser from the server, and make sure the browser is sending it back again on the next request.
Please verify if the session is not being invalidated in your code someplace. Look for code similar to request.getSession().invalidate();
If there is a load balance configuration, will must have to configurate a route in the network for preserve the requests in the same server. Otherwise, the each request will go to a different server, losing the session attribute.
Edit your tomcat context.xml file and replace <Context> tag to <Context useHttpOnly="false"> , this helped me.
Are you connecting via http or https?
For servlets the session I'd cookie has attributes 'secure' and 'httpOnly'. 'secure' means user agent will only send cookie if transport is secure (https/tls). If your connecting with http a new session is created on each request. 'httpOnly' means the cookie can not be modified by client side script.