When a session is invalidated in a web app, if i make to that app a new request with the invalidated jsessionid in cookie, what will be the new session's id? As i inspect, a new session is generated but the session id remains same. I couldn't give a explanation to this. Is there such a convention to keep jsessionid in cookie and give that value to newly created session or am i doing something wrong? :)
The Scenario.
I have 2 webapps on same weblogic. The WLCookie name for these apps are same.
When user enters in appA i am making a asynchronous call to appB's logout servlet where the appB's session is invalidated.
when user clicks a link in appA which refers to appB, i am creating a new session in appB and when i check for the sessionid in cookie it still remains same which is first created in appA.
As i know, two webapps on same weblogic does not share their session's if not configured but although i invalidated appB's session from outside why newly created session has still the same session id?
Thanks.
Do not confuse jsessionid with sessions. jsessionid is unique per container instance, where as session is per app. So, the session data won't propagate from AppA to AppB, just because the share the same jsessionid.
Related
Running our JRuby/Rails application locally on rails/rack, the session id is reset/renewed in
session/abstract_store.rb using the DestroyableSession destroy method.
Each new request coming in, using the same browser, will generate a new session id.
When the application is deployed to Tomcat and a request is completed.
If the same browser window is used and a subsequent transaction is submitted, the session
id remains the same between transactions and no new session id is created.
How does running on Tomcat cause the difference in session handling?
Tomcat is a servlet container designed to solve these problems for you. In particular it sets the JSESSIONID cookie to track the current session from the user.
Hi I have 2 wars on same machine. Let's say warA and warB.
When user is in /warA I have the sessionId of the same user in /warB. And i want to kill this session.
My aim is if user in /warA , i want to quarentee that the user session in /warB is killed.
Some can say write a servlet that kills /warB 's session and call it from /warA.
The reason i can't do this is, there is an agent(Oracle Access Manager) infront of /warB that do authentication part and don't let me call warB's servlet directly.
So is there any other way to do my job?
Edit:
I found this. Does OAM Agent breaks this request? Is it a simple request or a request between contexts?
servletContext.getContext("/warB").getRequestDispatcher("/logout");
If the two war files are deployed to the same WLS server, I believe this is the default behavior. WebLogic stored session id in the cookie named jsessionid, if you do not configure a different cookie name in the weblogic.xml. Thus if a user login war2, the jsessionid cookie from war1 will be overwritten and the session with war1 will not be maintained.
I'm using spring security core in my grails application. My app has lots of ajax calls which call controllers. Controllers in turn, depend on some session variables to fulfil the request. I'm currently able to correctly display the ajax login form on session timeout. However, it creates a new session with only the newly created user object. All other objects stored in session are lost.
Is there a way to reload session variables after a user logs back in after session time out?
the purpose of the session scope is that it's wiped when the session ends. if you need to share data between sessions, you should rethink your architecture and persist the data in a database (server side), or a cookie (client side)
(moved from comments into an answer)
I want to store some information of current session's user when a session is getting invalidated (because of time out). How can I do that?
If this helps, I'm using Spring Security 3.1. So if there is any configuration in Spring I'm having no trouble understanding that.
There is a thing in Spring Security as Session Expiration. When a session expires, a filter catches it and I can have my desired information from it.
However the problem is when a session gets invalidated (because of timeout). Because, for the next request there will be a new session created and I'm not able to have access to the old one. I want to know how I can customize session invalidation ?
Whenever you authenticate, your application should change the session identifier it uses. This helps to prevent someone from setting up a session, copying the session identifier, and then tricking a user into using the session. Because the attacker already knows the session identifier, they can use it to access the session after the user logs in, giving them full access. This attack has been called "session fixation" among other things. How can i change the session id once the user login to the system ?
You're still on the server while you invalidate the session.
//get stuff out of session you want before invalidating it.
currentSession = request.getSession(true);
UserProfile userProfile = (UserProfile) currentSession.getAttribute("userProfile");
//now invalidate it
currentSession.invalidate();
//get new session and stuff the data back in
HttpSession newSession = request.getSession(true);
newSession.setAttribute("userProfile", userProfile);
Get the existing; invalidate it; create a new one ...
1) Get the current Session with HttpServletRequest.getSession();
2) Clear the Session: HttpSession.invalidate();
3) Create a new one: HttpServletRequest.getSession(true);
Talking generally (because this isn't a Java problem at all, it's a general web problem) session fixation arises when session IDs are easy to discover or guess. The main method of attack is when the session ID is in the URL of a page, for example http://example.com/index?sessionId=123. An attacker could setup capture a session and then embed the link in their page, tricking a user into visiting it and becoming part of their session. Then when the user authenticates the session is authenticated. The mitigation for this is to not use URL based session IDs, but instead use cookies
Some web applications will use a cookie session based but set it from the initial URL, for example visiting http://example.com/index?sessionId=123 would see the session id in the url and then create a session cookie from it, setting the id in the session cookie to 123. The mitigation for this is to generate random session ids on the server without using any user input as a seed into the generator.
There's also browser based exploits where a poorly coded browser will accept cookie creation for domains which are not the originating domain, but there's not much you can do about that. And Cross Site Scripting attacks where you can send a script command into the attacked site to set the session cookie, which can be mitigated by setting the session cookie to be HTTP_ONLY (although Safari does not honour this flag)
For Java the general recommendation is
session.invalidate();
session=request.getSession(true);
However at one point on JBoss this didn't work - so you need to check this works as expected within your chosen framework.
Invalidate the current session and the get a new session:
//invalidate the current session
request.getSession().invalidate();
/*
get another session and get the ID (getSession()) will create a session if one does not exist
*/
request.getSession().getId();