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.
Related
I was wondering if there was a "standard" way for handling persitent HTTP sessions in a GAE based web app. Let me explain my issues.
If I only use this.getThreadLocalRequest().getSession() to get a session, this session will be automatically invalidated once the user closes the browser.
If I go with Cookies (so the session will persist until the cookie expires or the user erases his cookies), I need to have a kind of mechanism for validating that the sessionID stored in the cookie actually belongs to a valid session. I've thought about storing a key value pair of sessionID, HttpSession in a concurrentHashMap, but now I run into the problem that this hashmap will be available only for the current instance, therefore I might run into consistency problems.
The last solution I thought of was keeping track of the session in the datastore, but it seems pretty ridiculous to me having to query the datastore each time I receive a request.
Maybe I'm totally out of the track and there's a really simple way to achieve what I'm trying to do: Http sessions that persist across browser restarts and multiple gae instances.
Thanks!
Rodrigo.
You typically use a cookie to implement remember-me. The idea is to generate a random and unique cookie for an authenticated user, store it with the rest of the user information in the database, and send the cookie to the client browser.
Now, when the client comes back 5 days later, the cookie is sent with its first request to your application. At this time, if the user is not authenticated yet, you can extract the cookie from the request, find the user in the database who owns this cookie, and automatically authenticate him as if he sent his credentials.
This solution doesn't need to modify anything to how the sessions are handled by GAE.
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 have faced this question in my Interview as well. I do have many confusion with Session Scope & it management in java.
In web.xml we do have the entry :
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
What does it indicate actually ? Is it scope of whole project ?
Another point confusing me is how can we separate the session scope of multiple request in the same project? Means if I am logging in from a PC & at the same time I am logging in from another PC, does it differentiate it ?
Also, another confusing thing is the browser difference. Why does the different Gmails possible to open in different browsers ? And Gmail can prevent a session from Login to Logout. How is it maintained with our personal web ?
Session management is not something limited to Java and servlets. Here's roughly how it happens:
The HTTP protocol is stateless, so the server and the browser should have a way of storing the identity of the user through multiple requests
The browsers sends the first request to the server
The server checks whether the browser has identified with the session cookie (see below)
3.1. if the server doesn't 'know' the client:
the server creates a new unique identifier, and puts it in a Map (roughly), as a key, whose value is the newly created Session. It also sends a cookie response containing the unique identifier.
the browser stores the session cookie (with lifetime = the lifetime of the browser instance), containing the unique identifier, and uses it for each subsequent request to identify itself uniquely.
3.2. if the server already knows the client - the server obtains the Session corresponding to the passed unique identifier found in the session cookie
Now onto some the questions you have:
the session timeout is the time to live for each session map entry without being accessed. In other words, if a client does not send a request for 30 minutes (from your example), the session map will drop this entry, and even if the client identifies itself with the unique key in the session cookie, no data will be present on the server.
different gmails (and whatever site) can be opened in different browsers because the session cookie is per-browser. I.e. each browser identifies itself uniquely by either not sending the unique session id, or by sending one the server has generated for it.
logging from different PCs is the same actually - you don't share a session id
logging-out is actually removing the entry for the session id on the server.
Note: the unique session id can alternatively be stored:
in a cookie
in the URL (http://example.com/page;JSESSIONID=435342342)
2 or 3 other ways that I don't recall and aren't of interest
What does it indicate actually ?
The lifetime of a session. The session expires if there is no transaction between the client and the server for 30 minutes (per the code segment)
Is is scope of whole project ?
It has application scope. Defined for each web application
Another point confusing me is how can
we separate the session scope of
multiple request in the same project?
Means if I am logging in from a PC &
at the same time I am logging in from
another PC, does it differentiate it ?
Yes. The session ids (JSESSIONID for Apache Tomcat) will be different.
Also, another confusing thing is the
browser difference. Why does the
different Gmails possible to open in
different browsers ?
Each login by the same user from a different browser is a different session altogether. And the cookies set in one browser will not affect in another. So different Gmail instances are possible in different browsers.
And Gmail can prevent a session from
Login to Logout. How is it maintained
with our personal web ?
Persistent cookies
Servlets in Java have an HttpSession object which you can use to store state information for a user. The session is managed on the client by a cookie (JSESSIONID) or can be done using URL rewrites. The session timeout describes how long the server will wait after the last request before deleting the state information stored in a HttpSession.
The scope is per browser instance, so in the example you give logging in from two different pcs will result in two session objects.
if you open the same application in different window i mean multiple instance of a browser it will create different session for every instance.
I recommand Apache Shiro for session management,Authentication and authorization.
I take it back.
As #BalusC commeneted below, only servlet container is in charge of managing the http session. Shiro is just using that. It will hook to HttpSession via a filter you explicitly define.
we have 4 ways to manage a session.
1.Cookies
2.URL rewriting
3.Hidden form fields
4.HTTP session
the fourth one is powerful and mostly used now-a-days.
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.
I work on a task that involves moving/traversing from one application to another. The applications are in separate JVMs.
While traversing to the other application, I keep track of the session ID. However, as I traverse back and forth, a new session gets created. Is there any way for me to get back the same session, using the sessionId that I retain, when I navigate back into my parent application from a child application?
Environment: J2EE with WebSphere.
As mentioned by Mork0075, the sessionID is tied to the cookie name and the server domain. If you're using the same server domain for two apps on separate JVMs, I see two options to maintain the session when switching between applications:
The long shot:
1) If you're using a database for session replication purposes, you can use the same database for both applications, and the sessionID will be available for both apps. The one problem I see here is that the objects in the session may not be available on both sides, since the code would be different etc. They'd probably clobber the other side's session objects unless you maintained the code and such on both sides so the objects were available.
The likely possibility:
2) Use different cookie names for the session on one of the two apps. By default, sessions use JSESSIONID as the cookie, and when you switch to the second app, it tries to look up a session based on that cookiename and can't find it. So, it creates a new sessionID and sends it back to the browser, thus causing your sessionID to change and not be available when you switch back to the original app. However, if you change the second app's sessionID to something else (say, JSESSIONID2) your browser would end up with two valid sessionIDs that would each be valid on their correct application. You can change the name via the administration console under the application server's Session Management->Enable cookies page.
I'am not sure if this helps, but in a ONE application scenario, you would submit a sessionID with every reponse, save it in the URL, a cookie or as a hidden field. By submitting a new request to the server, the sessionID is also submitted, to resolve it at server side. In my understand switching from one application to another means, that you have to give the sessionID with the user, across the applications. If you save the sessionID in a cookie, this perhaps is not possible, because the cookie is restricted to a certain server domain. So ensure that the session is still valid and the sessionID is present after returning to the application started.
You shouldn't have to do this manually. Most app servers support Single Sign On (SSO) so that you can log in to one application and have access to all the applications in the same SSO domain. The app server will keep track of session ids and link them to an HTTPSession object specific to the web app.
See http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/ae/csec_sso.html