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.
Related
I am trying to wrestle with SSO in weblogic version is 12.2.1.3. We have integrated it with OAM/OID, within a larger application comprising of Oracle Forms & Reports. In addition to Forms, we have various custom servlet-based applications that need to be called from Forms.
This is fine.
Because authentication happens within the Oracle world, through OAM login screen, up to now I didn't have to mess with the Access Management within my Java custom code, apart from getting the username from HTTP headers.
The bad thing is that sometimes we need our servlets to act as middle-man between Forms and Reports. E.g. I need to call various stuff with Reports (on server), transform them and send them back to the client. I know that this doesn't sound right design-wise. But still it's legacy code and we need to make this work - at least need to try..
Previously we used to get away with it passing cookies between requests. But in 11/12g OAM, I am gathering from here that the cookie needed for successful session validation (OAMAuthnCookie) is stripped from the request before reaching my servlet. This seems to happen indeed, basing on the header dumps i am doing, and tracing calls using F12 Developer Tools on the browser.
So.. I have gathered that I need to generate a new OAMAuthnCookie, or something that would create it and attach it to the new http call.. I just would like an expert or somebody who has dealt with this to verify that the following assumption is right - the only way to do this is using OAM SDK (a bit non-intuitive imho).
Another thing - many of the examples that I find about OAM SDK deal with login forms. I don't need to do user authentication, nor do I need to talk with OAM myself to verify if the resource is protected or not. I am dealing with an already authenticated request - need to just somehow get UserSession and user token from HttpServletRequest, in order to generate new OAMAuthnCookie so that my next request (using e.g. apache client) succeeds.. I used to assume that this wouldn't be hard to do, but am a bit stumped now.
Thank you for your attention.
Working with OAM SDK, as far as I cursively saw (at the time of writing this, we were using Weblogic 12c with Access Manager that behaves exactly as described in the documents that talk about OAM 11g - therefore I assume that's the version we are using too), involves
generating ObAccessClient.xml from OAM Console, to establish contact between the code you are working on (which will be called Access Client), and OAM
including JARs from the downloadable OAM SDK with your application
writing code in your application (e.g. in authentication filter, or servlet) to establish communication with OAM via its SDK to finally authenticate/authorize etc.
There is a good guide about how to write the code in Oracle documentation here.
I found also these articles very informative:
Oracle Access Management blog
Oracle A-team Best Practices blog
The code that I had in mind would ultimately generate a new authentication cookie that I would pass to the reports servlet for further authorization (since this cookie is stripped indeed from the request before reaching my application). The only way I found to generate such a cookie would involve changing a setting in OAM console to include another cookie (OAM_IDENTITY_ASSERTION) in the requests, according to another Oracle A-Team article.
In the process of the above investigation, I finally stumbled on this magic reply to a question in Oracle forums. According to it, there is a user setting in OAM console, that allows to switch off the default filtering of OAMAuthnCookie.
filterOAMAuthnCookie=false
In our case, this perfectly suited me. Indeed after the change, the cookie in question was finally reaching my application, with the result of me being able to pass it to subsequent requests to Oracle Reports, without using OAM SDK.
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.
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.
In a web application based on propraietery MVC and authorization model, we have recently migrated to Spring MVC.
As part of that move, we are also looking at moving away from a locally created GUID that is passed with each request to a cookie based Session ID.
On the face of it, it looks as if in our case, doing so will be a big disadvantage as the standard JSESSION/HttpSession seems to be the root of all security evils:
Session Fixation (In existing code session is only created after succesful login, so we need never invalidate() a sessions.
CSRF - Session is never passed as a cookie so this is never a risk (and god, it's a problematic one to handle since there is no real framework or generic solution out therem checked HDIV and CSRFGuard).
Testing Useability - QA can easily have multiple users with multiple roles connecting to the same Server, not possible with JSESSION.
In consistent HTTPSession creation and invalidation in various Containers (Weblogic, JBOSS and Websphere)
Inconsistent JSession handling when moving between HTTP to HTTPS.
So, other than the obvious advantage of "being standard", Any clues as to why would I want to go the JSESSION route?
Not really a categoric answer about why you should or should not use jsession, but stil some remarks regarding your concerns:
Your application should not rely on the fact that a session exist or not. It should rely on the fact that the session is valid according to certain rules you put on it (user authenticated, roles assigned to this user, etc...)
CSRF is not really a big deal as long as you take care to not use GET for sensible actions, and as you mention Spring MVC, it is quite easy to achieve with it.
True, if you only rely on one browser. And as a side note, while manual testing remains a must for some situations, many use cases can benefit from automation, and thus reduce the impact of having to switch from a role to another.
Never encounter a problem with that. But I tried to kept the content of the session as small as possible.
And that's a good thing. It can prevent you from moving away from your secure connection without noticing it.
Now, whatever the option you'll choose, there will always be some drawbacks. Having a UUID in each request (and thus potentially in each GET URL) does not allow your users to use bookmarks easily. Nor to keep their session alive.
After much discussion analysis and testing, it seems that tleast in my case, a non RESTfull application, with a desktop like RIA UI, and extensive security considration, JSESSION is not the way to go (CSRF mainly) and a better option is a BODY based internally generated key.
This does mean though, that the application will be forced to handle timeouts and session invalidation.
We are running tomcat application server that handle over 100 concurrent sessions.
In the last 2 months the most active users noticed that sometimes they are getting kicked off from the system.
As I understood from the log tomcat sessions are getting expired without any reason.
I see no problems from the web application side.
Is there any problem from the tomcat side?
Tomcat 6.0.18.
If there has been no code change triggering this, I would look at memory usage. This might be the effect of Tomcat running out of memory and invalidating sessions to recover.
If at all possible monitor garbage collections, and/or put surveillance on with jconsole Java Flight Recorder or jvisualvm.
A possible cause is that you put in the session an object that does NOT implement the Serializable interface. Tomcat occasionally writes some of the sessions on the disk. If a session contains non-serializable objects it will simply be removed from the container (because of the NotSerializableException). If this is happening you should see the Exception in the tomcat log file.
I would increase the monitoring of the server in general and the sessions specifically.
A good monitoring application is lambda probe - it allows you to view the current sessions and their data. I would also add a HttpSessionListener to log session creation and destruction.
Edit
Is is possible that you add some non serializble objects to the session and Tomcat fails to passivate them to the disk?
Edit 2
Lambda probe seems to be dead, and there a much better fork of the project over at http://code.google.com/p/psi-probe/
there is a timeout, that you can configure in your web.xml:
<web-app>
...
<session-config>
<session-timeout>-1</session-timeout>
</session-config>
</web-app>
use -1 for no timeout
Increase your logging of sessions, which may shed some light onto your problem.
The Tomcat config page's Logging in Tomcat includes an example of increasing logging of sessions.
We just ran into this with tomcat 6_0_18 and ibm 1.5 jvm
turns out it was an ibm jvm issue with atomic operations.
There is a fix in tomcats greater than 6_0_19 to handle it.
It also doesn't occur in sun 1.5 jvm
here are some more details
tomcat bugzilla case
I have seen similar problems when the following prerequisites exist:
multiple instances of the tomcat app are installed across multiple JVMs
load balancing (between the web server and the Tomcat JVMs) is not configured correctly.
Tomcat's session replication feature is not enabled
Due to the incorrect load balancing config, the web server may randomly decide to break session affinity and send an incoming request to a Tomcat JVM that has never seen the session before. The Tomcat JVM will issue a new session and the user will lose all of their previouS session data and effectively start over.
You can search Tomcat's bug database, but it would be better to have another look at your web application first. The chances that there is something wrong with Tomcat are very low.
Try to investigate what causes session invalidation. Are you using filters? Do you have cross-context requests? Try adding logging information for every request to find out, when exactly the session is lost.
I had a similar symptom (but more consistent). Users would sign in ok, go to the dashboard ok, then loose the session.
I realized I had done a Java 16 to 18 upgrade and had not recompiled everything. Cleaned (mvn clean) and recompiled the code for ALL my .jars/.war.
Problem solved, for me.
I hope this helps someone.
Eventhough I do not know the cause of the problem, one possible fix (which I had done at my previous project) would be to run the application on a tomcat cluster and have session failover. Sessions can be by default sticky and when one node goes down, the healthy nodes pick up the sessions and all this is transparent to the end user.