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.
Related
We are using Vaadin 14 on a Tomcat9.
A session is immediately created in Tomcat as soon as the login page of our app is called up. If a lot of sessions have been created here (e.g. penetration test), the Tomcat takes a very long time to delete them. The CPU load also rises to 100%.
Is it possible to prevent the automatic creation of a session and only create one after the login?
We have reduced the session timeout in Tomcat so that there are not so many open sessions.
You can not use Vaadin (for your Login) and no sessions. Vaadin stores the
state of the UI in the session and there is no way around it:
A user session begins when a user first makes a request to a Vaadin servlet
by opening the URL of a particular UI. All server requests belonging to
a particular UI class are processed by the VaadinServlet class. When a new
client connects, it creates a new user session, represented by an instance of
VaadinSession. Sessions are tracked using cookies stored in the browser.
https://vaadin.com/docs/latest/advanced/application-lifecycle/#application.lifecycle.session
So you have to prevent this and not send your users directly into the
Vaadin application (first). In your case you could provide a login form
or some SSO gatekeeper to "protect" your resources.
In a spring MVC app , does closing the Application browser window ends the session ?
And when a new window is opened then a new session is started
Is my understanding correct?
Starting with some details first and then answering your specific questions below.
If you have a network inspection tool, you'll notice that the first time your browser interacts with the server, there is a header in the response that looks like Set-Cookie: JSESSIONID=<session_id> (assuming Tomcat). The server has created a session and has given that session ID. The server will typically create a new session when either the request did not have a session ID or the session ID was invalid. This cookie is stored in the browser's cookie store and will be sent in subsequent requests as a Cookie header.
If the cookie does not define an expiration, the browser will treat this cookie as a session cookie, which is transient or will only live until the browser is closed. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie.
So closing your browser would only lose the client-side reference (session ID) to the session. While the session on the server is orphaned (assuming nothing else has a reference to the session ID), the session is still very much alive. If there are no further requests for that session, the session will eventually timeout and end. You can configure the timeout via this property - server.servlet.session.timeout.
Now to answer your exact questions:
Q: Does closing the Application browser window ends the session?
The browser cookie store will no longer contain the session ID after closing. The server session will be orphaned and eventually timeout/end.
Q: And when a new window is opened then a new session is started
If the browser is already open and you made a request the server once before, opening another window that hits the server would not create a new session. Both windows share the same cookie store.
But if you were to open a new window after launching the browser process or clearing your cookies, a new session would be created. Again, this is due to the request from browser to server not containing the session ID.
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.
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)