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.
Related
Apologies if I sound bad.
I have a xyz.war that does some authentication and sets a cookie(with HttpOnly set so I can not expire it via javascript) so that when the user logs-in for the next time the session is maintained. Now, given that I have the access to the Tomcat that is hosting the xyz.war how can I write a Java program that could expire/delete the cookie? I can create a .war of the java project and host it in the same Tomcat and access it from client side via a api.
You would have invalidate the session in xyz application. Removing (thus beeing able to midify) cookie by third parties would be a security hole.
How do I logout the authenticated session in weblogic once the server timeouts as per the configured value in deployment descriptor (web.xml)?
It seems by default server calls httpSession.invalidate() method once the server times out. httpSession.invalidate() does not logout the authenticated user.
But I need to programatically call weblogic ServletAuthentication.invalidateAll(HttpServletRequest req).
Thought of using HttpSessionListener but how do I get hold of the HttpServeletRequest object?
Any solution will be appreciated.
Thanks in advance
When the session is time out, the user is automatically logged out. If you refresh the page you will be redirected to the login page.
We are facing one issue in a Struts application deployed in JBOSS clustered environment with load balancer and sticky session
Issue description
1) This issue happens in a user registration functionality which has 2 pages, register1.do and register2.do page
2) When user clicks on registration url, https://ourwebsite.com/register1.do
Two GET request are made
GET register1.do (Gets 1st registration page and sets few values in session)
GET captcha.do (This loads a captcha image to be shown on register1.do)
3) Sometimes what happens is GET request to register1.do sets a JSESSIONID cookie and the GET request to captcha.do over write JSESSIONID cookie set by first request. This causes problem in 2nd registration page as it fetches some of the values stored in session and as the session is overwritten by captcha no values can be obtained.
see below image
4) This scenario does not happen every time, once this issue occurs and if we go back to register1.do page a refresh(F5)/hard refresh (Ctrl + F5) then GET request to captcha.do does not over write JSESSIONID cookie and user registration works fine.
Moreover this happens only in clustered environment, in single JBOSS environment it works fine.
Can anyone please help me to identify what could be possible problem
here ?
Why session does not get over written when we do a page refresh ?
Update your apache mod_cluster binaries to mod_cluster 1.2.6.Final which are available here.
This solved it for me, which was jumping servers after every single refresh. Hopefully that helps.
I also experienced the same problem with jboss eap 6.1 and in load balancer i'm going with mod_cluster configuration I changed algorithm from server per session to entry per session and sticky session is working well and good .Go through the following to know about entry per session and server per session.
Entry-per-Session means that the device creates additional client-table entries whenever a source IP opens a new session (unique source port). This gives the unit more accurate tracking of the number of sessions, but it's behavior is to continue sending all the traffic from the client's source IP to the same server.
In Server-per-Session mode, the device tracks the unique source ports the same way, but when the client opens a new session, the device makes a new load-balancing decision for the new session. This way multiple sessions from the same client IP can be 'sprayed' among all the servers rather than being stuck to a single server.
I have been having an issue with session variables not being available when a request has come from a domain name as opposed to localhost. For instance, if I set a user variable:
request.getSession(true).setAttribute("user", user);
//Redirects to another html page or something...
When the client makes another request and I attempt to access the user session variable it returns null.
//Client makes another request to the server
request.getSession(true).getAttribute("user"); //returns null
I've noticed that on each request, a new JSESSIONID cookie is set and the ID value changes. Does this mean that a new session is being created each time the client accesses the server? How do I maintain the same session between the client so I can store objects in the HttpSession and have access to them?
I don't know if this has anything to do with anything either, but when viewing the application from the tomcat manager, the sessions count continues to grow regardless of the fact that I am using the application from the same browser window, not refreshing the page or anything. Another sign that a new session is being created on each request to the server?
This only happens when accessing the application from a domain name ex: example.com/app. When coming from localhost, the session variables work fine.
Update
I tested without using response.sendRedirect and the session variable is available until I switch pages and make another request to the server. This confirms my suspicions that a new session is being created with each request. Its not the redirect thats killing the session, its any new request. How do I prevent this?
How are you doing the redirect? Are you calling HttpServletResponse.encodeRedirectURL() beforehand?
Read the javadoc here
You would use it like response.sendRedirect(response.encodeRedirectURL(path));
The issue was with the path in the JSESSIONID cookie. I still can't figure out why it was being set to the tomcat application path /tomcat-app-name/ but I changed the cookie configuration in the web.xml to:
<session-config>
<cookie-config>
<name>JSESSIONID</name>
<path>/</path>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
</session-config>
And now the session variables are working across sessions. Of course, now the session variables don't work when running using localhost. Instead you can set the sessionCookiePath on the context.xml root context node:
I'm using ubuntu server and tomcat7. For tomcat7, the context.xml can be found at /etc/tomcat7/context.xml.
<Context ... sessionCookiePath="/" > ... </Context>
Now, you should be able to run locally (if you didn't change that cookiepath on your local machine) as well as on the server without having to configure the JSESSIONID cookie in your apps web.xml.
I'm having a problem with java sessions.
I'm developing a simple web app, where I have to use sessions and session attributes. Everything is fine until I close my browser. When I close my browser the JSessionId disappears.
Here's my code:
request.getSession().setMaxInactiveInterval(30*60); //it's 30 minutes
request.getSession().setAttribute("someinteger", 10);
It works great, but when I shut down the browser, and reopen it I can't find the jsessionId (before I closed the browser I could find it in the 'localhost' section). The strange thing is I can still find the "someinteger" cookie. What is the problem? What am I doing wrong?
I'm using this, too: link text, and it shows that JSESSIONID cookie expires : "SESSION", and "someinteger" expires in 30 minutes
Thanks in advance.
Session cookies don't persist across browser restarts. Thus, the JSESSIONID cookie won't exist when you re-open the browser.
Actually the reason is that the session timeout defined in the web.xml is probably still set to its default:
<session-config>
<session-timeout>30</session-timeout>
</session-config>
The session cookie will persist across browser restarts if the browser has been configured to (all do by default). The cookie with the JSESSIONID is not a special cookie to the browser, it's just another cookie.
If you look at the cookie you can see when it is set to expire. Cookie expiry and persistence is independent of session timeout. Except that the cookie is what connects the browser to the seesion.
If either the cookie or the session are lost, then the session is effectively lost.