I faced a very strange behavior with WildFly 8.x (tested with 8.1 and 8.0 also). If I deploy my WAR as ROOT (set the '/' as context-root in jboss-web.xml) my JAX-RS resource classes will have different session IDs (each resource class will have a unique session id). But in fact, if I set anything else other than '/' as the context-root everything works as I expected originally (every JAX-RS resource class share the same session).
I know that REST services are stateless and I don't have to worry about sessions but I'm so curious why it behaves like that. Does anyone have any ideas?
Thanks!
Here's a sample minimal project where you can reproduce this issue: https://github.com/aberkes/cdi-sessionscoped-bean-demo
The idea is that by default if you deploy to ROOT, jboss doesn't use a fixed cookie path parameter. This is made for the case, when you have other applications running in different sub-folders and requiring their own independent sessions.
To change this behaviour, you may use the
<session-config>
<cookie-config>
<path>/</path>
</cookie-config>
</session-config>
parameter in your web.xml. Then all jsessions will be bound to the root path.
Related
Suppose I have one web application ABC , ABC has one link for module Name XYZ which is deployed in other JBOss or Wildfly server. When user login into application ABC , and click on link XYZ I have to use same authentication of ABC to XYZ. What is the proper way to do it ?
The Web (Undertow) Reference Guide for Wildfly (which was last updated July, 2014) states this:
Sharing sessions between wars in an ear
Undertow allows you to share sessions between wars in an ear, if it is explicitly configured to do so. Note that if you use this feature your applications may not be portable, as this is not a standard servlet feature.
In order to enable this you must include a shared-session-config element in the jboss-all.xml file in the META-INF directory of the ear:
<jboss umlns="urn:jboss:1.0">
<shared-session-config xmlns="urn:jboss:shared-session-config:1.0">
<session-config>
<cookie-config>
<path>/</path>
</cookie-config>
</session-config>
</shared-session-config>
</jboss>
This element is used to configure the shared session manager that will be used by all wars in the ear. For full details of all the options provided by this file please see the schema at https://github.com/wildfly/wildfly/blob/master/undertow/src/main/resources/schema/shared-session-config_1_0.xsd, however in general it mimics the options that are available in jboss-web.xml for configuring the session.
This was added in WFLY-1891 (Fix Versions: 8.2.0.Final, 9.0.0.Alpha1), the comments on which note that it doesn't work in a cluster (as of April, 2014).
See also another SO post - Session sharing on WildFly is not working
Edit:
WFLY-3270 - Clustered support for HTTPSession sharing between wars delivered in an EAR notes that clustering was resolved in 9.0.0.Alpha1.
Is there a way of deploying a tomcat webapp with different web.xml (different name and context)?.
The problem:
I have a web.xml which i constantly have to modify (comment out and uncomment) stuff as i develop things - and this makes it a little annoying. Want i want to have is lets say two files:
web.xml
web-dev.xml
And I want my tomcat on my local machine to use web-dev.xml. Ofcouse for production release (i.e. Hosted server Tomcat will be using normal web.xml - web-dev.xml won't even be published). Its just for the development.
Any ideas where i can specify within tomcat to use web-dev.xml instead of web.xml ?
Thanks
Similarly to #HumbertoPinheiro, I think Maven profiles are a way to go.
Alternatively, this seems like a possible solution (Reference link : Specify a custom web.xml to an embedded tomcat):
Context webContext = tomcat.addWebapp("/yourContextPath", "/web/app/docroot/");
webContext.getServletContext().setAttribute(Globals.ALT_DD_ATTR, "/path/to/custom/web.xml");
Tested on Tomcat 7.0.42.
I'm deploying a web application and I want to have a default 404 page applicable to all my web applications unless stated otherwise in each application web.xml
I've accomplished something changing "jboss-as\server\myapp\deployers\jbossweb.deployer\web.xml" and adding the following
<error-page>
<error-code>404</error-code>
<location>/error404.html</location>
</error-page>
Then all 404 errors I get are redirected to /error404.html without changing each application's web.xml as I wanted.
Anyway the bizarre thing is that each war I'm deploying must have a error404.html copy because it's looking for it in its own context. I tried putting error pages in jboss-as\server\myapp\deploy\ROOT.war and they work for non-defined URLs but not for already defined applications.
Can I have only one copy of my error pages for ALL contexts and that page defined only in one web.xml?
Thanks a lot in advance.
Rafa,
is "myapp" a custom profile you created? If not then try changing the file /jboss/server/all/deployers/jbossweb.deployer/web.xml.
Where "all" is one of the available jboss profiles (all, default, standard, ...).
I am trying to migrate the deployment of some applications from tomcat 6 to jboss-as 7.
A single sign-on mechanism has been implemented for these projects, which, in order to work, needs to have crossContext="true" set in the tomcat context.xml file and emptySessionPath="true" in the connector configuration found within server.xml.
How can these settings be mimicked in jboss7? I know that jboss uses a modified tomcat as a servlet container, but I have been unable to find any of these settings.
Found this: http://community.jboss.org/message/617186
Not sure if it works though...
Servlet 3.0 specification supported by JBoss 7.1 allows specification of session cookie path in web.xml. Just put this fragment to all of your wars whose context you want to be shared:
<session-config>
<cookie-config>
<path>/</path>
</cookie-config>
</session-config>
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