In IE 8 when we open two different browser windows we get the same session unless we use the File -> New Session option.
We have two different applications (j2ee) that use the same domain name. This works perfectly fine in IE 7 when the user opens the two applications in two browser windows. However, in IE 8, what happens is that the browser treats both applications as one - and the session is shared. Now, is there any fix that can be done in the application to ensure that we detect a new window (new session) being opened?
Usually you'd host the two applications on different paths, right? If that is the case, just limit your session cookie to the path of the application. So, if you have one application on the path /app1 and the other on the path /app2, then the session ID cookie for the first app should look like:
Set-Cookie: JSESSIONID=SOMEVALUE; path=/app1
There should be mechanisms for setting this in your application server. If you give some more details on the application server then we can probably guide to the exact configuration element that needs to be changed.
Related
I have two sailsjs applications running on the same machine (locally), with the first providing REST endpoints for the second. I use the same browser to interact with both the applications. The apps run on different ports.
The problem is, each time I access one application from the browser, the session for the other gets lost, requiring me to login every time I use the browser for testing the REST endpoints. I tried setting the same session secret for both application as a wild guess but it didn't work.
Is there a way to get around this?
I'm using Firefox and the applications are hosted on localhost:9999 and localhost:1337.
Thanks in advance.
You can store your session in your database, that's what connect-mongo does, for instance. I'm sure you can find something like that for sails too.
The issue was that Sails uses the same cookie name/key ('sails.sid') for each application by default. Accessing different Sails applications made the browser override the same session cookie, leading to the described condition.
Changing the key for every application fixed the problem.
In config/session.js, include a key attribute and set it to something application-specific to avoid using sails.sid.
I launched two different instances of JBoss AS 7.1 on my machine on two different ports and deployed the same application (with the same root context) to both of them. This configuration gave me, deterministically, the following exception as I was doing tabbed browsing with the same browser (either Chrome or Firefox or Conkeror):
javax.servlet.ServletException: viewId:/whatever.xhtml - View /whatever.xhtml could not be restored.
javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62)
When I was browsing with different browsers things were ok.
Upon further investigation on how different browsers store cookies I discovered that the combination (IP / path) has to be unique to avoid such tabbed browsing problems and that the port does not come into play. I.e. cookies are stored per IP and per path but not per port. So doing tabbed browsing with the same browser on two different applications deployed on the same IP and path (but obviously on separate ports) will result in expired views as the browser mixes up the two sessions. I recognize that my setting is unlikely to arise in a production environment but I would like to ask:
is there any standard that defines this cookie organizing behavior?
are there any best practices one must be aware of in order to avoid session mixups when doing tabbed browsing in multiple JSF applications?
does the javax.faces.STATE_SAVING_METHOD have any bearing on this (in my setting it was set to "server") ?
is there any standard that defines this cookie organizing behavior?
Version 0 cookies (Netscape spec cookies) do not support ports in any way.
Version 1 cookies (RFC2965 spec cookies) supports the Port attribute. If this is absent, then version 0 behavior is used.
The average servletcontainer sets the JSESSIONID cookie as a version 0 cookie. You could theoretically override this by providing a custom "Session Manager" in the servletcontainer. Note that MSIE 9 does still not support version 1 cookies.
are there any best practices one must be aware of in order to avoid session mixups when doing tabbed browsing in multiple JSF applications?
The canonical approach in real world projects is to use a different subdomain (on same port!). E.g. beta.example.com, dev.example.com, update.example.com, test.example.com, etc.
does the javax.faces.STATE_SAVING_METHOD have any bearing on this (in my setting it was set to "server") ?
If you set it to client, then the ViewExpiredException will indeed disappear as the view is not stored in the session anymore, but instead in a hidden field of the form. But you might still face other session-related trouble, for sure if you're storing some stuff in the session, such as session scoped managed beans and the logged-in user.
I am using Spring acegi security for single sign on on multiple applications. I need to extend session timeout at client side if user writing something on browser too. If user opended multiple sessions or browsers then i need to consider active session on all the sessions he opened. If he is active then i should not log off him eventhough he is inactive in another sessions.
Please suggest me any ideas how to track and know at the client side too.
Any idea is greatly appreaciated. Thank you.
Running application app1 in two tabs say tab1 and tab2.Timeout is 10 minutes. So we implemented timeout functionalit in java script which is at client side. This code gives Confirm box after 10 min. If user says continue, we are extending the session by firing the alive url. This working if application running in a single tab. Same applciation app1 open in multiple tabs say tab1,tab2. Here applicaiton app1 opened in two tabs but single session. We are woking the application which is opened in tab2 and not using applciation in tab1. So application in tab1 is inactive for 10 min.then application in tab1 giving confirm box and we dont answer to that confirm box tab2 will make applciation to log out. So what is the solution for not making logout as we are working application on Tab2. Any ideas? How to track whether application in active in other tabs?
This is not straigt forword answer. (Since I do not think there is a solution for that)
you could try to fire a pixel(*) between the application and by that extends the session time.
lets say that you have:
app1, app2, app3
the user logged in to app1 and app2 and he is working only on app1. if you fire a pixel from his browser to app2 every http request he made on app1, he suppose to be alive on app 2 as well.
I think that if you fire the pixel every 2 minutes between the applications app1,2 and 3 you can save the session alive between the apps.
I have done this twick in PHP application, it wans'nt so easy, but it is doable.
*pixel - it is a hidden http request that runs a script in the serverside. can do it via ajax, img, script src="", iframe and more.
You should be able to store a lastActivity timestamp in localStorage
User activity in any tab updates the lastActivity timestamp
Whenever the timer expires in any tab it should check the lastActivity value before prompting the user. If lastActivity is older than timeout, prompt the user. If not, adjust the remaining time to show prompt
The simplest thing would be to associate the sign-in session with a shared domain. Say you have app1.domain.com, app2.domain.com, app3.domain.com, BUT you have the SSO take place on domain.com, and they all share that session cookie. This is just a matter of setting the domain on the session cookie-- I believe you can do this in the configuration. Anyway, this pretty easy to do, so if this works with your problem, go for it. (Maybe there's some tricky way to do this without that domain hierarchy, but I'm not sure what it is.)
If that isn't workable, you may need a different way to store sessions. My first thought would be to put the sessions in the database. With these, you can synchronize and centrally manage the timeouts. This may require a little bit of custom code-- but it shouldn't be that much.
Not sure this is applicable, but I wrote my thoughts on implementing timeout on the client side as well.
Modified code in javascript to fire ajax request to server and finding the latest activity.
If latest activity is less than 10 mins then there is no logout.
I found that IE7 maintains same session for multiple tabs in a single browser window and thus doesn't support different sessions for different tabs in a single browser window. My client needs that the application should work perfectly in two different tabs in a single browser window. i think this is because of session and cookie problem. Is there a workaround for this.
Appreciate your help in this regard.
Thanks,
Manoja Swaro
Browser tabs share cookies (and not just in IE, in Firefox and the others as well), and the cookies contain the session ID.
You could switch to cookie-less sessions however this has security and usability concerns. URL based sessions are easily hijacked, and it breaks bookmarking as well, as each page has a unique URL per session.
IE7 doesn't maintain a 'session' as such, you're talking about a cookie with a session ID in it, I would guess. All browsers will have one value for a cookie, it doesn't vary by window/tab.
If you want a session ID to travel with the click trail, you're going to have to pass it from page to page, by (for instance) passing it as a URL parameter and ensuring that you add the parameter to the URL within the page. (Or do without a session.)
The real solution is to change your application so it doesn't assume each session has only one page. An application that can't be open in multiple tabs is broken.
This can be hard if this assumption is already deeply embedded in your code.
I use a web application that forces you to reauthenticate with the application even if you open a new browser window that shares the same session, e.g. File, New Window in Internet Explorer. I was surprised since I thought that if you opened a new browser window from File, New in both IE and Firefox (vs. starting a new browser process) that it would share the same session.
Using an Internet Explorer cookie viewer/editor, I saw no cookies for this application at all.
How do they likely implement this forced authentication scheme that seems to disallow new browser windows from continuing the session?
One common approach is to pass a session ID in the URL.
For instance, asp.net uses this approach for cookieless sesssions. URLs within the application are rewritten to contain a session ID.
there are two possibilities for this:
it's session id stored in all <a href=''> , so clicking on link automatically sends some data to server.
Same, but with POST queries (hidden form fields)