If a user opens 2 web pages simultaneously they will create 2 sessions.
Usually this would not matter but it does create a problem for remember me functionality when attempting to rotate cookie tokens as recommended in the persistent login cookie best practices. There seems to be no way to rotate both cookies correctly where both sessions are opened simultaneously.
How can I resolve this?
I use Tomcat and Struts 1, but I think this is framework independent.
extending #Thilo answer He is correct, any subsequent access to other page will follow send the cookies for that domain. e.g open gmail, login and now open gmail in other tab or window it send the cookie for that domain. since the cookie hold the session information on any subsequent request only session id/value will be changed.
You can check it using firebug and its extension fire-cookie.
On matter of avoiding remember-me problem as said in the link you specified it is more to design problem as how you are handling it.
Related
I am creating one web application in java. I am using session for this application. when i deleting cookie from browser at that time my session is invalidate. i want to prevent that thing.
for ex:
when you are logging in banking website. after logged in website you remove cookie from browser you are still logging in website.
Anyone know how to store session of user when clear the cookies.
There is no way to. If the user deletes cookies, there is no way to identify him in subsequent requests.
There are some "hacky" ways to do it (for example this), but I don't recommend you to do this. What's the reason to? Cookies are standard.
I know following are the ways to maintain or session tracking in java but looking for a good one
URL rewritting
Hidden form fields
cookies
Session object like setAttribitute() and session.getAttribute()
If the client browser has blocked accepting and storing cookies then last 2 ways are not valid.In hidden form fields I need to pass the hidden values in each and every page inside form.So suppose If I am just using response.sendRedirect() Then hidden form field is of not use.The remaining is URL rewriting in which I will pass JsessionID in the URl.So My question by knowing the sessionID isnt the unauthorized persons can able to access the pages.
For example There are 3 pages login,register,send.So after login user can register and/or send.So if any one knows the sessionID cant he/she go direct to register/send page.If yes Please tell me how to prohibit this
As of Servlet 3.0 (Apache Tomcat 7 onwards) if you use SSL then you can configure your application to track sessions based on the SSL session ID. The downside is that everything has to be over SSL. The advantages are that the session is strongly tied to the SSL connection. Only the user that created the connection to the server that has the correct SSL session has access to the session. Even if an attacker knows the session ID, they can't access the session.
One word of caution, this form of session tracking is the least widely used so it may not have been as heavily tested as the more usual cookie and URL re-writing mechanisms.
Have a look at this link which outlines Best practices for using HTTP sessions
Including
javax.servlet.http.HttpSession.invalidate()
Use HTTPS
With standard solutions you can't.
You can add some measure of security by adding request originator IP address verification, but that's also fooled easily. (to clarify some here means very tiny itsy bitsy little bit of)
So the secure route is to not use URL Rewriting to maintain session in secure application.
However you may be able to get some security by keeping the JSessionID as a separate encrypted attribute that which will be decrypted by a middle-ware or a load balancing server sitting between the client and your application servers. This of course is just a thought, I haven't, fortunately ever had to try something like that out :-)
Session tracking & authentication are two diff things don't club them.
Understanding your requirement I see you want to secure the sessionid of the user.
Evasdroping: If someone is listing to the request & response in the middle he can take the sessionid and use it. The best way would be to use a SSL. This ensures no one is listening in the middle.
Sessionid stolen from Client side: Normally this should be taken care by the browser and OS. So your user is as secure as the system he has.
As per my understanding same session is shared among different tabs of same browser window. And for different browser window , different session
is created. Now some questions on my understanding:-
1)When i hit my web application in two different browser window, i see same jsession id on firefox console. How same session session is
shared among two different browser window. As by default session is maintained through cookies with the help of jsessionId which is created
by webserver. Other way of maintaining the session thru URLRewriting where we maintain session by passing jsessionId in each url request.
I can see using org.tuckey.web.filters.urlrewrite.UrlRewriteFilter in project but this class document does not seem to do any magic much session maintenance.
I am not getting how come same session is attached with two different browser window and techinical approach to do it
2)similary when i hit two different application under two different tabs of same browser window
probably google and some other website say yahoo, i dont see same jsessionId in firefox console for these two website. Is the website
doing some special stuff here to generate new session for each Tab? In fact for some website(probably for google) i do not see jsessionId at
all under firefox window. How its possible. My understanding it is generated automatically by webserver and is passed either by
cookies or URLReWriting?
It would be helpful if somebody can answer inline to my question as its important to understand each point posted here for session management
UPDATE:- Let me put my questions with different scenarios:-
1)Hit two different URL(say google.com and stackoverflow.com) in two different tab of same browser window.
My Understanding:- Two session will be created as two cookies will be created for two different domain/port
2)Hit two same URL(say stackoverflow.com) in two different tab of same browser window.
My Understanding:- Onesession will be created as same cookies will be reused
3)Hit two same URL(say stackoverflow.com) in two totally different window of browser (firefox).
My Understanding:- how many session will be created in this case?
Your first assumption is not correct. If you use session management with cookies (default for Java servlet containers) then your session is visible in all windows of the same browser instance.
If you configure your Java servlet server to use URL rewrite only for sessions, then you can have one session per tab.
Usually two different Java web applications will always create two different session cookies only valid for its own application scope. The cookies are bound to the domain and path.
Other web frameworks like PHP can handle this totally different.
The cookie jsession_id is created by the server, which sends it to the browser in return for a request through a HTTP header Set-Cookie . The cookie is stored on the client by the browser. Henceforth, the browser will resend that cookie for every subsequent request on the same domain (the cookie can be restrained with secure and path https://en.wikipedia.org/wiki/HTTP_cookie#Terminology but it is irrelevant here).
The browser has access to that cookie from all tabs (basic rights and security) and it is a design choice if it separates sessions (same cookies on all tabs) or merges them (same cookies on all tabs, therefore same session on all tabs within the same domain). As far as I know, all browsers choose to share cookies on tabs but I am no expert.
So in order to maintain session on multiple instances of the same java program, you need to do the same and store your jsession_id cookie (and reuse it if relevant) outside of the memory of each instance (for example on file). This might not be trivial if security is important.
As to point 2, it is important to understand that even though both cookies are jsession_id, they are related to different domains (and have been set by each server) so there is no reason for them to be equal.
As the title said, I want to remove the cookies when I close a window. I know of the methods for cookies like Cookies.removeCookie(Constants.XXX); And also of cookie.setMaxAge(0);
for removing cookies. But that is done on clicking logout.
I want to remove cookies on window close or when application has stopped running. Because whenever, I am debugging the application, whenever I rerun the application, I see the cookie is still there even though I am not logged in, and the session has not started for the user. So there is a conflict, where the cookie is already set even though, the user has still not logged in !
Its a GWT Application.
First of all, it's important to differentiate between a cookie on the client side, and a session on the server side (I think you already knew that).
Usually, for a clean logout, you'll want to call session.invalidate() on the servers side, and Cookies.removeCookie(...) on the client side.
But not every 'logout' is clean:
The logout request may not make it to the server
The browser may crash even before you call removeCookie - so any attempt to remove a cookie on window close will be unreliable
On the server side, you can use timeouts (see the link provided by #thinksteep: How we call logout servlet on browser close event).
For the client side cookie, you can set an expiryDate/maxAge. Or you can use "session cookies": These are the cookies where you don't set expiry or maxAge at all. Most browsers will delete "session cookies" automatically when the browser restarts - but please see Firefox session cookies.
All of this may mean, that cookies are maybe not the best technology for your use case: In general, a cookie is by design available in all browser tabs, and the concept of a browser session doesn't even always end, when the browser/window closes (what would it mean on a smartphone anyway?). This is desirable for many current web sites (users don't have to log in explicitly every time), and many users have come to expect this kind of behavior.
For sites that want a "one tab = one session" policy, it's possibly better to store a token e.g. in a Javascript (or GWT) object, and send it with every request. This way, you can log in separately - even as different users - from multiple browser tabs, and once a tab closes, the token is gone. Please note, that a tab may still get restored by the browser on session restore. (I would always combine this technique with a httponly cookie, to avoid certain kinds of attacks.)
In my Java EE application, I have a problem with sessions. Different users can login to the application and the specified user can see the data for which he is authorized. He should not be able to see other user data. To differentiate users, we are using Client_ID. As soon as the user logs in we are fetching this Client_ID from the database and setting it in session like this:
session.setAttribute("Client_ID",user.getClient_ID())
We access this session value throughout the application and fetching the relevant data to that Client_ID. This works fine when users work on a single browser, but the problem is this:
Suppose there is a SuperAdmin, who needs to look all the clients under him. SuperAdmin logs in as client_1, and again as client_2. SuperAdmin has logged in both times using the same browser. When I refresh the client_1 browser, I am seeing the client_2 details, which should not happen.
I think our application is using the same session for two different logins in the same browser. What would be solution for this problem? I should see the correct data for the particular client when I refresh the page.
Don't use cookies for storing Session ID, but use request parameter instead.
So each opened tab will request the own session. With cookies you have only one cookie for all tabs in browser.
P.S.:
I think that it's incorrect to log in under 2 or more users within one browser at the same moment. Your application should detect that client_1 is already signed it and restict log in for other users from the same browser until logout. For example, Google's applications work in such way.
Also would be great if SuperAdmin have a feature to see client_1 or client_2 data without log in. This will save him/her from remembering dozens of passwords and will increase performance of work (time is moneys, isn't?).
If you want multiple tabs within the same browser instance to see different things, then you will have to rework your session management and key things off of the URL.
The session is shared between browser tabs (true for most browsers), so logging in with one tab will affect the sessions for other tabs.
The solution is to use roles instead of multiple logins. You would give client_1 SuperAdmin role, and client 2 doesn't. This would reduce the need to login twice.
But in any case, you should only allow one user to be logged in at once. The process of logging in should invalidate the previous session. I forget the exact code in Java EE, but it is something like session.invalidate().