Suppose I have a web app with a servlet defined in web.xml.
Then I deploy it on Tomcat.
Then I open my browser and go to the link to this servlet, it is invoked.
Then I close my browser window.
How Session behaves ? How is it created, destroyed in this case?
if this servlet is "detached" from all the web app, and gets parameters only using post & get, so it does not need Session at all, should one use Session.invalidate at the end of doGet(), doPost() ?
The servlet container usually keeps track of session using either (1) a HTTP cookie or (2) adding an extra parameter jsessionid in each URL.
When a user access this site and no session exist already, a new one is created for him, including the corresponding HttpSession. If necessary, the user might be redirected to a login page.
The effect of Session.invalidate will basically be: "Discard the current session for this user. If he access another page on the site, a new session will be created".
So far I know, session invalidation is used typically to implement logout feature.
I wouldn't call Session.invalidate in your "detached" servlet, it will interfere with the other pages. Basically, you don't care about the session in your servlet, you don't use it anyway.
Maybe have also a look at this question about disabling the session.
Then I close my browser window.
How Session behaves ? How is it created, destroyed in this case?
Are you asking what happens if the browser is closed even before the response is received back at the client?
In such a case, a Session will still be created on the server. It will persist for a specified time period and then expire.
The next request from your browser will create a new Session.
See more on this here: http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html
Regarding session.invalidate - ewernli has already answered.
Related
According to http://www.ibm.com/support/knowledgecenter/SSAW57_7.0.0/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/cprs_best_practice.html?lang=en
Avoid trying to save and reuse the HttpSession object outside of each servlet or JSP file :
The HttpSession object is a function of the HttpRequest (you can get
it only through the req.getSession method), and a copy of it is valid
only for the life of the service method of the servlet or JSP file.
You cannot cache the HttpSession object and refer to it outside the
scope of a servlet or JSP file.
I don't understand as here it is said the contrary : https://docs.oracle.com/cd/E11035_01/wls100/webapp/sessions.html
Session tracking enables you to track a user's progress over multiple servlets or HTML pages
The one from Oracle is good. If for example you set the session attribute "USER" when the user logs in, the user's session is available across all the pages. The session expires based on the time you configure in your web.xml environment for example when you use Tomcat.
Here is what I found from the doc :
https://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html
Provides a way to identify a user across more than one page request or visit to a Web site and to store information about that user.
The servlet container uses this interface to create a session between an HTTP client and an HTTP server. The session persists for a specified time period, across more than one connection or page request from the user. A session usually corresponds to one user, who may visit a site many times. The server can maintain a session in many ways such as using cookies or rewriting URLs.
Hope it helps!
Here's my situation, I have a web site that I just load using Apache HTTPD that then makes Ajax POST requests to a servlet which returns only JSON data. That JSON data is then used to update tables, etc..
Now I want to add user logic to my site, and also maintain servlet sessions for requests made by individual users.
I understand that the servlet needs to return the session id generated by the first call to request.getSession(), so that the client can add this sessionid to future Ajax requests in order for the servlet to know which session in memory to use.
I also understand that the two ways that this session id can be returned to the client is either using cookies (JESSIONID) or URL Rewriting.
If I can't use URL Rewriting, because I'm just returning JSON data, are cookies the only way I have left to send back the session id to the client?
Also, as a side question, currently I noticed that there is no JSESSIONID cookie in any of my HTTP responses from the servlet. Someone suggested to me that this was something new in Tomcat7 and that I had to activate them in the global context.xml. Does this mean that by default there is no session handling even if you make calls to request.getSession() ?
You have correctly identified two of the three ways of handling session IDs supported by Tomcat. There is a third way to track sessions but only if the application runs over SSL. In that case you can configure Tomcat to use the SSL session ID.
If the Servlet calls request.getSession() then Tomcat always includes a session ID in the response. However, those cookies are marked as httpOnly by default in Tomcat 7 onwards which means they are not visible to javascript (to protect against XSS attacks that try to steal the cookie). If the session cookies need to be visible to script then you need to set useHttpOnly="false" in either the web application's context.xml (to change the default for just that file) or in $CATALINA_BASE/conf/context.xml to change the default setting for every web application.
I'm supporting some project, built using ADF (using JDeveloper 11.1.2.2.0) and deployed to Tomcat 7.0.28.
There was an issue with JSessionID:
IT should be different before logging-in and after it. To solve this, in my method validate() (that is executed when user submits login form) I do the following:
ExternalContext ec = FacesContext.getCurrentInstance().getExternalContext();
HttpSession session = (HttpSession)ec.getSession(false);
session.invalidate();
session = (HttpSession)ec.getSession(true);
//setting some special session attributes
ec.redirect("nextPage");
When I arrive to nextPage I can get session with special attributes set above and go further. Everything works good when I log-in from Firefox or Chrome.
But when I log-in using IE 8.0 and get redirected to nextPage, my code gets session without those special attributes and throws me back to login page.
Using Wireshark I've realized that when Firefox logs-in it sends POST request with user input (username/password), receives answer with new JSessionID in SetCookie parameter, sends another request with Adf-Window-id and receives answer, after that it is redirected to nextPage.
But for IE flow is different: on log-in IE sends two POST request in a row (first with user input, second with Adf-Window-id) and after that receives two answers, each with different JSessionID. It stores the last one and gets redirected to nextPage. Obviously, the last JSessionID belongs not to the session where I've set my special attributes.
I've already spent few days trying to solve this problem by digging configs and Google, with no success. All I can see - IE sometimes can log-in as expected (in this case two answers mentioned above are received in reverse order), but it happens seldem.
Maybe you have faced same problem and solved it? Or maybe I'm doing/expecting something wrong?
Actually what you do cannot work. When you perform Java EE container managed authentication then you authenticate the user session. If you invalidate the session then the user authentication is gone as well. The only way this can work is if you use Basic Authentication, in which case the browser sends use credentials with each request.
Oracle WLS has a proprietary method for this that allows to renew the session ID without invalidating it. Similar seems to exist for Tomcat, see here: http://www.koelnerwasser.de/?p=11
I've solved the problem described by implementing my own servlet.
After successful logon the necessary session attributes are set and the session is not invalidated. Then, user gets redirected into context of my own servlet, which saves all session attributes, invalidates the session, creates new one and restores old attributes. After that, this servlet redirects user further, where he should get after logon. Of course, there are some tricks for security.
I have developed 1 web application but when multiple users are login on the same browser than jsp page of first user is changed by jsp page of second user.
There is no way you can have multiple sessions simultaneously using a unique browser. Each time you create a new session, the session cookie which is used to track the current session is replaced by a new one.
That's because your browser doesn't use a new session for each open tab. If you are using firefox you can install a special plugin to handle that behaviour for you. http://blog.techno-barje.fr/post/2009/12/05/Session-per-tab-in-Firefox/
Explanation on Spring Security FAQ page should answer the behaviour you encountered:
Browsers generally maintain a single session per browser instance. You
cannot have two separate sessions at once. So if you log in again in
another window or tab you are just reauthenticating in the same
session. The server doesn't know anything about tabs, windows or
browser instances. All it sees are HTTP requests and it ties those to
a particular session according to the value of the the JSESSIONID
cookie that they contain. When a user authenticates during a session,
Spring Security's concurrent session control checks the number of
other authenticated sessions that they have. If they are already
authenticated with the same session, then re-authenticating will have
no effect.
I am having some issues with my web application while doing a performance test with Jmeter. My question is not around Jmeter instead, it's around a simple Servlet session management behavior.
So we have a web application, where in when you request a login page, it passes back a "Session Id" in response headers and that is used for subsequent request made by browser. Session Id is passed along with username and password and if authenticated a new session id is returned and session is maintained with that session id going ahead.
This is using cookies.
Now in Jmeter we have a thread based approach for load testing. When I run threads parallely what is essentially happening is that each thread request a login page and somehow only the last thread to request login page is authenticated as I feel that subsequent login page that comes with a new session id in cookie, invalidates the old or other session ids.
This is inspite of the fact that each thread is a different session and has it's own cookie manager. It's quite wierd.
However my questions are:
Does it make sense to have session id coming with login page; I see that maybe session is created as soon as application is accessed, but is it that, what sets a new cookie with session id? This application was already written so I am just wondering.
If each thread's session id is being overriden in jmeter does that mean, that i am not able to allocate a seperate cookie manager properly? Also even if threads are different sessions is there a possibility, old session id or cookie would be discarded?
How would Server know to invalidate the session id/cookie for subsequent requests? I am sure, not basis of IP address of requestor, as different browsers would still let me open parallel multiple sessions.
Any ideas, clarifications and light on the issue would be much appreciated.
Server will just timeout the session it definitely sounds like you are over writing cookies here.
Have you tried seeing how it manages by including session ids in the url (simulate cookies being disabled in the browser) Does this work?
Has this been solved at all?
I would say that having a session id in the login page is quite unusual. Session are meant for storing data server side and associate that data to connected users. Of course, prior to authenticate the user, there shouldn't be any data server side.