We are experiencing a strange behaviour, we have an application (jsf 2.2.4 embedded) that has a login form, glassfish has sso enabled and a custom realm (LDAP). We have also several applications (some with jsf 2.2.4 embedded, others using jsf implementation of glassfish) that are linked by the application that contains the login form.
For some reason when glassfish has created 300 - 400 sessions approximately or cpu is at high rate or maybe at a random moment, and we navigate from the main application to the others and then return to the main application, at some point glassfish changes the jsessionidsso cookie, assigning a new one. The thing is that sometimes that cookie represents the session of another user, so thats where we have a session mix and can see the information of another user.
We are running Glassfish-3.0.1 on a Centos-6.5, no proxy.
We have already tried updating weld following this guide http://www.andygibson.net/blog/quickbyte/updating-weld-in-glassfish-v3/ but we are currently experiencing the same behaviour.
Can someone point us to the right direction? What could it be?
Thanks so much!
Regards,
Mateo.
We have the same problem and don't know the reason yet. Our temporary solution: we attach the user ID to every user request and we check the permissions of that particular user every time, because we unfortunately can not trust to the session id. If the session does not belong to the user ID, we reject the request and ask the user to initiate a new session. The problem affects less than 1 percent of sessions.
We suspected the load ballancer system in front of the Glassfish servers, but if someone has the same experience without load ballancer layer, the problem hides somewhere else.
Related
I am facing issue with shiro.
We have two applications(two WARS) on the same weblogic server 12c.
One WAR is UI which was integrated with CAS.
Second WAR is Jersey Rest services.
My problem is UI was auntheticated succefully and JsessionID was passed back to Rest Services while communicating with them.
Before reaching to the service we wrote one shiro filter class each time Subject is valid or not.
And also in our UI there is a requirement to call the Rest Service (One specific service) in every one minute.
Issue: Each time call reaches to shiro filter class, we are getting the different subject. i tried to print the sessionId from subject (each time its different), even though user was authenticated successfully in UI and in the backend some time user name is shown as null. Can you pls help.
Subject subject = getSubject(request, response);
There are a few things that typically cause this.
If you are handing the login yourself (by calling something like subject.login() directly, instead of letting the ShiroFilter handle it)
Both application servers are managing the sessions outside of Shiro: See https://shiro.apache.org/session-management.html#session-storage
That said, I'd need more details of how your app is setup. What do your cookies look like, how are your app servers configured, etc.
My tomcat application randomly invalidates the session information and the user if forced to log back in again. This only happens when the webapp is deployed with other specific web applications. When it is run by itself with no other app running, it works fine. There is a conflict somewhere, but I am unable to find it.
The webapp in question uses both the Spring and Hibernate frameworks. The other webapps do as well. Here is an example of what happens.
When I first log on, everything is fine.
JSESSIONID Matches
The JSESSONID matches in both the cookie and the management console. However, when using the application, it randomly terminates the session.
Session gone in Tomcat Console
When I another web request, the login page is shown and a new JSESSIONID has been generated.
From the research I have done, the JSESSIONID is generated whenever a JSP file is called and there is no current session. I don't understand why the session is being invalidated, but only when it is run alongside other applications. I have checked the memory usage, and I didn't notice a correlation between a memory drop and the sessions being invalidated. I guess that means that Tomcat isn't clearing sessions to free up memory.
Any help is much appreciated
Check that session.setMaxInactiveInterval() is not programmatically configured in the other web applications. This would elicit the behavior you describe.
This method is slightly different from the session timeout value that you would find in your web.xml files. (Here's a good rundown.)
the following steps may help you:
Are you sure that you did not override the default session time out value, Please check out your session time-out at runtime.
from tomcat manager page (~/manager/html/list) see the status of your web application sessions and press on the value of your app sessions column.
I have a legacy application that runs on Spring 1.0 with Acegi security on JBoss 4. Our plan is to migrate one subset of the application to Tomacat 7 and Spring 4. The user will login to the legacy application but if they want to navigate to the subset that is being migrated they would be redirected to the new app.
My question is how would I maintain session information between the two so that the user can seamlessly navigate between the two apps and maintain SSO. There would be no other information exchanged between the two servers. One constraint we have is that we have to make minimal changes to the existing legacy app.
Any help would be much appreciated.
You can't seemlessly maintain session information as far as I can tell.
You might be able to get insanely lucky by configuring JBoss and Tomcat to be clustered using Tomcat's clustering (and assuming that the Tomcat version shipped with JBoss is compatible with the standalone Tomcat you are running), and then enabling SSO on both JBoss and Tomcat, but then you have to be very careful not to place anything in your JBoss session that is not going to be loadable by the standalone Tomcat instance.
You are probably better-off implementing some other solution like using SAML that will likely be less fragile.
You said you didn't want to make too many changes, but if you are willing to get your hands dirty, you could use a shared URL-space between the web applications, use different session id cookies, and then cross-check incoming requests for unauthenticated users by calling-over to the "other" server to fetch their authentication information (which you'll have to make available in the session in some way). I'd advise against storing passwords in the user's session.. instead allow one application to obtain the username of the user in the other application using the session cookie from the first. Trust that the username is accurate and that the user has been correctly authenticated already in the first application, then perform an auto-login into the second.
Whatever you do, it's going to get messy, since your requirements are fairly messy.
I'm debugging an issue where calls to our weblogic server often return with a new JSESSIONID value, replacing the JSESSION that was originally sent.
The issue occurs frequently, but not consistently. (Ie., when it affects you, it affects ~90% of your traffic.)
We've shown that the issue appears to be unrelated to the actual server call being made, which makes it hard for me to debug any specific method.
Is there a way to hook into the JSESSION creation in WebLogic, to see what is causing the session to be created / destroyed / invalidated?
Attaching a remote debugger would be great, but I'd settle for some form of logging that might point me in the right direction?
This is a standard part of the servlet spec (not WebLogic specific). You want the HttpSessionListener interface.
Note that the Servlet session stuff is really bad - the kind of behavior you're seeing can happen when memory problems kick in, etc. For a deconstruction, check out the presentation at SeaJUG (Rethinking Users and User Session Management). Slides and video are posted.
Nodemanager/WLST is something that is also useful in debugging and monitoring servers with Weblogic Admin, Enterprise Fusion Middleware Control, or Cloud Control.
In my web appication i need to recognize signed in users even if they restart the browser ("Remember me" function of web sites). What is the best practice to achieve this using Java Servlet API?
I've considered the following options:
Using long-term HttpSession sessions and storing user identifier as an attribute of the session. This approach doesn't permit user to restart browser, because JSESSIONID cookie is not persistent and there is no standard way to change its properties. The only option i consider is to use SessionCookieConfig interface of Tomcat 7.0 to tune default JSESSIONID parameters. But there are doubts about the scalability of such solution, because Tomcat will store all sessions for a long period of time.
Using short-term HttpSessions together with some persistent cookie which stores the user identifier with some security hash. When user restarts the browser, it sends persistent cookie and application server binds new session with user identifier.
What is the common way to achieve this?
I have always needed more control over my sessions, because I need them to work across multiple web applications, so I implemented my own solution from scratch. It is pretty easy, just hash a random number and store it in a database. If you don't have or want a RDBMS just some sort of key/value store.
Are you using normal filter-based authentication? How secure does your site need to be?
One way:
Drop a cookie with a code in it on their browser. In Tomcat, have a typical filter configured. The filter grabs the code and checks it against the database for validity. If the code is valid the normal Tomcat authentication is avoided. If there needs to be any persisted session variables, you can load them from the database now.
Drop a new cookie code with every response. It should include a hash of a salt, the user's ID, and the user's IP address. That way the cookie will do no good if the request comes from the wrong computer. Though IPs are spoofable.
Bear in mind, you're short-circuiting security when you do this. You're saying, "Oh look, you've just come out of nowhere. I think I know you! Here, have the keys to my castle!" This sounds like the sort of request we'd get from the marketing folks who didn't understand a thing about security and didn't care since it wasn't there problem if we got hacked.