We Keep Coding

How to prevent jboss node name from being added to sessionid

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

LTPA2 token name won't change

we have a complex infrastructure with WebSEAL, Websphere Portal and a couple of Wesphere AS' where we [obviously] want to set up SSO. we successfully configured TAI++ etc, but unfortunately default LTPA2 token name ("LtpaToken2") is not acceptable for compatibility reasons and we want to change it. Websphere AS 8.5, that we're using, has a special option in "General security -> Single Sign-on" to do so, but that doesn't work however; no matter what we enter, the token issued is still named "LtpaToken2" (well, yes we restarted the AS apparently ;P).
is it something known around websphere community? afaiu this can be customized by implementing a token factory and a token interceptor/validator (i.e. as is suggested here: Generate LTPAToken 2 in custom Web Application), but i'd expect the edit-box that supposedly does so to actually work.
BTW, i take it that renaming LTPA2 tokens is not at all possible in earlier Webspheres?

It is definitely possible since v8. I've tested it on 8.5.5.1 and works fine (I can set ltpa cookie to any name). Verify your settings accessing directly to WAS for example - in admin console, not via TAM. Your problem might be related to WebSEAL and Tai.
I don't quite understand what you mean that ltpatoken2 is not acceptable for compatibility reasons? It was always like that, so changing it will rather introduce incompatibilities, than keeping the default.

Accessing session attributes in weblogic vs tomcat

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!!

Spring security: using relative path

I have an application with name test.war.
Because of Apache installed on my server I have to use another port number for Tomcat applications so after deployment this application available at domain.com:8080/test/.
I decided to create a subdomain in order to remove that ugly 8080 from url, so I setted up the server like described here. So now test.domain.com reffers to domain.com:8080/test/.
Everything seems fine except of one problem - because my application is not ROOT.war and I am using spring:url function every url in the application is translated to /test/bla-bla. So I removed that function. But still have a problem with spring security because it still translates an urls relative to app name i.e. /test/bla-bla.
How can I solve that problem?
Thank you
UPD: I don't want to deploy it as a ROOT application because I have two or three such applications and I wanted to create a subdomain for each one of them

Spring Security doesn't "translate" URLs. In fact this isn't specific to Spring Security. You'll run into similar issues with any application which does redirects. If you want to hide the context paths of applications which are behind a proxy, then you need to rewrite the URLs at the proxy.
I'd recommend you read the Tomcat Generic Proxy Howto and the section on URL rewriting in particular, as it specifically addresses this issue.

Resolving Session Fixation in JBoss

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