I have a web application where I want to track which language a user wants to use to view the various pages. I am using a session attribute to store their selection. I set the session attribute like so...
String languageChosen = request.getParameter("LANG");
request.getSession().setAttribute("LANG", languageChosen);
Then in other methods I retrieve the attribute like so...
String languageChosen= (String) request.getSession().getAttribute("LANG");
When I test this application in my local environment - which is running Tomcat - it works perfectly. But when I deploy the application to our remote development server - which is Weblogic - the session attribute is not being captured. As a result the application is not displaying in the right language.
Should I be storing the session attribute differently for Weblogic? I've never run into this issue before. We have other apps running on the same Weblogic instance that utilize session attributes without issue. Any ideas?
I figured out the problem. The current development URL is not a secure URL and I had the secure cookie setting set to TRUE in my weblogic.xml file. Once I changed it to FALSE everything worked.
Now I just have to remember to change it back to TRUE when we move to a secure environment. Ha ha!!
Related
We have a java web application which was hosted in tomcat 8. For session Management , we have been using the memcache which maintains non sticky based sessions. This has been working fine without any issues.
Now there is a requirement to upgrade the tomcat from 8 to tomcat 9 and the upgradation with the necessary jars for the tomcat 9 has been done. After the upgradation, we are facing an issue in the application where the session is becoming null. Some of the link in the app associated with the session are working fine and some of them when clicked gets me logged out of the session. Checking the logs, I see the session object null.
The memcached jars used as part of the tomcat 9 and copied under tomcat9/lib
memcache-session-manager-2.3.2
memcache-session-manager-tc9-2.3.2
jettison-1.1.jar
spymemcached-2.12.0
http-core-4.3
http-core-nio-4.3
we are using the 3rd party Serialization for this use case and they are also copied in the tomcat lib folder
kryo-3.0.3.jar
kryo-serializers-0.37.jar
minlog-1.3.0.jar
msm-kryo-serializer-1.9.3.jar
objenesis-2.1.jar
protobuf-java-2.6.1.jar
reflectasm-1.10.1.jar
With these jars , I am able to see the tomcat startup without any issues.
**<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:ip:port"
lockingMode="auto"
sticky="false"
requestUriIgnorePattern= ".*\.(png|gif|jpg|css|js)$"
sessionBackupAsync= "false"
sessionBackupTimeout= "100"
copyCollectionsForSerialization="false"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>**
Followed the below link for setting up the memcache configuration in my application.
https://github.com/magro/memcached-session-manager/wiki/SetupAndConfiguration
Please help me if i am missing anything in the configuration.
Thanks
Pradeep
Have solved this issue by removing the param **requesturiignore pattern ** from the context.xml as this was creating different sessions.
Recently, we have upgraded our application server from JBoss EAP6.2 to EAP7.0.
Even though it runs non-HA profile aka standalone.xml, JBoss adds jboss.node.name at the end of JSESSIONID cookie.
For example,
Spring Boot generates a JSESSIONID as tHSf9v23SSDBMqJ1O7XFJZ9.... and when the request comes to browser, the cookie becomes tHSf9v23SSDBMqJ1O7XFJZ9.master:<jboss.node.name> which causes some compatibility issues.
I've run some experiments by manually calling response.addCookie. In that case, it does not add master suffix to the cookie. However, if Spring itself writes the cookie, it seems that JBoss picks it up and add master suffix. I know this case can be little confusing (it is to me), I'm happy to provide more information.
An old thread, but for those who still stumble upon it:
In EAP7/Wildfly11+ the session cookie will have a value in form :
<sessionId>.<instanceId>
Where instanceId is taken from Undertow subsystem config attribute instance-id. By default it is going to be set to value of jboss.node.name system property in standalone mode, and to <serverGroup>:<hostname> in domain mode.
You can customize the instanceId value via Undertow subsystem config:
Either via standalone.xml:
<subsystem xmlns="urn:jboss:domain:undertow:3.1" instance-id="${myValue}">
Or via corresponding cli:
/subsystem=undertow:write-attribute(name=instance-id, value=myvalue)
In which case you get a final JSession id that looks sth like this:
JSESSIONID=FdEyt_nZvyAV1gKpQ_3ZsSYeu41JycphvMdHcYeT.myvalue
The answer from #yntelectual is dead right and should be the accepted answer.
I just want to complement the fact that the observed behaviour is not a JBoss speciality.
It was introduced so Apache mod_jk and mod_proxy know which one of several possible application servers is working on a given session, and Apache Tomcat as the reference implementation for servlet containers shows exactly the same behaviour. Other containers such as JBoss, Glassfish, Geronimo do the same.
Check
jvmRoute on https://tomcat.apache.org/tomcat-9.0-doc/config/engine.html
jvmRoute on https://tomcat.apache.org/connectors-doc/reference/workers.html
route on https://httpd.apache.org/docs/2.4/mod/mod_proxy.html
jvmRoute on https://docs.oracle.com/cd/E18930_01/html/821-2416/gfaad.html
jvmRoute on https://geronimo.apache.org/GMOxDOC11/geronimo-tomcat-host-level-clustering-sample-application.html
I'm trying to have my JSESSIONID at ".mysite.com" so it can be shared across subdomains.
I have a 4.2.2 GA JBOSS instance doing this with this method: http://shchekoldin.com/2010/05/27/sharing-jsessionid-across-subdomains/ (which is from here: https://jira.jboss.org/browse/JBWEB-107) using the custom valve approach.
However on the EAP 5.1 version (I've compiled against JDK 1.6) the same custom valve doesn't kick in. I added some debugging but it never gets called.
Also, I tried turning on the SSO option in server.xml (as per https://community.jboss.org/wiki/JBossWebSingleSignOn) through the non-clustered method, but this plays no impact on it either.
Does anyone know how I can the JSESSIONID cookie to sit across subdomains on JBOSS 5?
(Side note, if I have "foo.bar.mysite.com" will this ".mysite.com" domain stored against the cookie work for multiple sub domains - this is for testing, in prod we just have the one level).
I also had same requirement. Share session across sites having sub-domain and parent domain within same .war file. e.g www.baseball.sports.com and www.hockey.sports.com.
To share JSESSION b/w these two sites need to add domain tag in jboss-web.xml.
File path : /app/jboss/jboss-eap-6.1/standalone/deployments/mason_production/.ear/.war/WEB-INF.
Add below entries :
.sports.com
I found what I needed:
You add <SessionCookie domain="example.com"/> under in the WEB-INF/context.xml of your application.
I have a java web application. When I log in to that application and navigate to a jsp which has flex chart embeded into it, the chart displayes just fine. I am using blaze ds remoting object mechanism. But when I want to navigate to a different page, it logs me out of application since the login session is lost.
The HTTP session is backed by a HTTP cookie which is tied to a specific domain and by default also the context path. So if you lose the session, then it may be caused by navigating to a different domain and/or context path. It's however also possible to invalidate the session programmatically by calling HttpSession#invalidate().
So to fix your problem, you need to ensure that you're navigating to a page in the same domain and context and that your server side code is not unnecessarily calling invalidate() somewhere.
If the problem is actually caused by a switch in the context path and you'd like to get it fixed, then you need to configure it in the servletcontainer. It's unclear which one you're using, but in for example Apache Tomcat you would like to set the emptySessionPath attribute of the <Connector> element in /conf/server.xml to true. Also see this document.
I need to prevent Session Fixation, a particular type of session hijacking, in a Java web application running in JBoss. However, it appears that the standard idiom doesn't work in JBoss. Can this be worked around?
This defect (found here) points the way to the solution. The Tomcat instance that runs in JBoss is configured with emptySessionPath="true", rather than "false", which is the default. This can be modified in .../deploy/jboss-web.deployer/server.xml; both the HTTP and AJP connectors have this option.
The feature itself is used to eliminate the context path (eg. "foo" in http://example.com/foo) from being included in the JSESSIONID cookie. Setting it to false will break applications that rely on cross-application authentication, which includes stuff built using some portal frameworks. It didn't negatively affect the application in question, however.
This problem and the specific case in which it occurs is a problem in Tomcat as well as JBoss. Tomcat shares the emptySessionPath="true" effect (and actually JBoss inherits it from Tomcat).
This really seems like a bug in Tomcat and JBoss when you are trying to prevent session fixation attacks but the servlet spec (at least version 2.3) does not actually require the JSESSIONID to be defined or redefined according to any specific logic. Perhaps this has been cleaned up in later versions.
One workaround is to store the client address in the session. A response wrapper should validate the client address set in the session is same as the one accessing the session.
I came to know below code setting snippet from one of the forum. And I added below lines. But when I print the session ID after and before log in into the application it is same. How would I test session Fixation.
D:\jboss-5.1.0.GA\bin\run.cof file and add the below line.
set "JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK=false"
in each context.xml of the jboss applications.
D:\jboss-5.1.0.GA\server\default\deploy\jbossweb.sar\context.xml