How do I set X-FRAME-OPTIONS in JBoss EAP 6.1? - java

I am running a java spring application on Jboss EAP 6.1
X-FRAME-OPTIONS in the request header when performing a file upload is DENY and I receive the following errors. The file upload also does not appear on the page.
All of the solutions I see online say that I should try setting this value to SAMEORIGIN. They also show how to configure this in Apache but does anyone know how I set this option for Jboss?

Ok the other way is to create a HTTP filter.
Create a class that implements javax.servlet.Filter
Annotate the class with #WebFilter("/*") or the context you need.
In the doFilter method set the HTTP header you need and do not forget to call chain.doFilter(request, response); afterwards.
Build this class into a JAR and make sure it is placed in your WEB-INF/lib directory.

See the answer to this question system-properties In standalone-full.xml
In your standalone XML you can set the Apache Catalina properties like this:
<system-properties>
<property name="org.apache.tomcat.util.http.Parameters.MAX_COUNT" value="5000"/>
</system-properties>

Related

How to change Cookie Processor to LegacyCookieProcessor in tomcat 8

My code is working on tomcat 8 version 8.0.33 but on 8.5.4 i get :
An invalid domain [.mydomain] was specified for this cookie.
I have found that Rfc6265CookieProcessor is introduced in tomcat 8 latest versions.
It says on official doc that this can be reverted to LegacyCookieProcessor in context.xml but i don't know how.
Please let me know how to do this.
Thanks
You can try in context.xml
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
reference:
https://tomcat.apache.org/tomcat-8.0-doc/config/cookie-processor.html
Case 1: You are using Standalone Tomcat & have access to change files in tomcat server
Please follow answer by #linzkl
Case 2: You are using Standalone Tomcat but you don't have access to change files in tomcat server
Create a new file called context.xml under src/main/webapp/META-INF folder in your application & paste the content given below
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>WEB-INF/tomcat-web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
</Context>
When you deploy your application in Standalone Tomcat, the context.xml file you placed under META-INF folder will override the context.xml file given in tomcat/conf/context.xml
Note: If you are following this solution, you have to do it for every single application because META-INF/context.xml is application specific
Case 3: You are using Embedded Tomcat
Create a new bean for WebServerFactoryCustomizer
#Bean
WebServerFactoryCustomizer<TomcatServletWebServerFactory> cookieProcessorCustomizer() {
return new WebServerFactoryCustomizer<TomcatServletWebServerFactory>() {
#Override
void customize(TomcatServletWebServerFactory tomcatServletWebServerFactory) {
tomcatServletWebServerFactory.addContextCustomizers(new TomcatContextCustomizer() {
#Override
public void customize(Context context) {
context.setCookieProcessor(new LegacyCookieProcessor());
}
});
}
};
}
Enabling the LegacyCookieProcessor which is used in previous versions of Tomcat has solved the problem in my application. As linzkl mentioned this is explained in Apache's website https://tomcat.apache.org/tomcat-8.0-doc/config/cookie-processor.html.
The reason is that the new version of Tomcat does not understand the . (dot) in front of the domain name of the Cookie being used.
Also, make sure to check this post when you are using Internet Explorer. Apparently, it's very likely to break.
You can find context.xml in the following path.
tomcat8/conf/context.xml
<?xml version="1.0" encoding="UTF-8”?>
<!-- The contents of this file will be loaded for each web application —>
<Context>
<!-- Default set of monitored resources. If one of these changes, the -->
<!-- web application will be reloaded. -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<!-- Uncomment this to disable session persistence across Tomcat restarts -->
<!-- <Manager pathname="" /> -->
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor"/>
</Context>
The problem is still with Tomcat9. Same process need to follow for Tomcat 9 to set the class.
Add the class in context.xml file.
If you are using eclipse to run the application, need to set in the context.xml file in the server folder. Refer the below screenshot for more reference.
Hope this helps someone.
SameSite issue in tomcat version < 8.5.47 has resolved
In Tomcat 8.5.47 and bellow (Tomcat 8 versions), setting CookieProcessor tag to enable same site (as given bellow) in context.xml does not work due to a bug in Tomcat.
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" sameSiteCookies="none" />
If you find in this situation where it is not a easy thing to upgrade tomcat immediately (which I faced recently), or if you find any other case where you just need custom processing in cookies; You can write your own CookieProcessor class to get around.
Please find a custom CookieProcessor implementation and details of it's deployment steps here.
In my case I wrote a custom CookieProcessor based on LegacyCookieProcessor source code that allows tomcat 8.5.47 to enable SameSite attribute in cookies.
As mentioned by #atul, this issue persists in Tomcat 9. It will most likely persist moving forward with all future versions of Tomcat, since this is the new standard.
Using the legacy cookie processor (by adding the line above to the context.xml file) is working well for us. However, the true 'fix' is to adjust how your cookie is formed in the first place. This will need to be done in your application, not in Tomcat.
The new cookie processor does not allow the domain to start with a . (dot). Adjusting your cookie (if possible) to start with a value other than that will fix this problem without reverting to the old, legacy cookie processor.
Also, it should be obvious, but I didn't see it mentioned above: after updating the context.xml file, you need to restart the Tomcat service for the change to take effect.
Cheers!

Keycloak-Tomcat-Adapter: Is there a alternative path for 'keycloak.json'?

I try to secure my Java Servlet application with keycloak. All works fine but I don't like the fact that my 'keycloak.json' file is inside my release located. The reason is, if the keycloak definitions are inside my war, so I need for different installations different build processes or the same client credentials on different installations.
My idea was now to place the 'keycloak.json' outside my WEB-INF. Is this possible? Other ideas to solve this problem are also welcome.
if you check the KeycloakOIDCFilter you see there are three additional parameter.
keycloak.config.resolver
keycloak.config.file
keycloak.config.path
We are using file parameter and works like charme.
The Servlet-Filter mentioned above is not necessary.
It is enough to set a context-parameter, like #OkieOth said in his comment.
E.g. set a Parameter like this
<Parameter name="keycloak.config.file" value="MY-PATH/keycloak.json" override="false"/>
within your context (beside the for keycloak configured Valve) or a "context-param" in your web application deployment descriptor (/WEB-INF/web.xml):
<context-param>
<param-name>keycloak.config.file</param-name>
<param-value>MY-PATH/keycloak.json</param-value>
</context-param>
For more Detail about context-params, see The Context Container in section "Context Parameters".

How can I change jboss logging level to show which java class I am calling?

Is it possible to set up jboss to show which URL I called, which class I am calling, and what parameters I sent to it?
I set my class log4j.xml to TRACE, but that may not be the right .xml file to change. It didn't seem to do anything. Maybe I'm not looking at the right log? I only see boot, errFile, and server.log.
Thanks for any help.
You may want to enable RequestDumper.
In Jboss 4.x.x it can be found in the file
.../server/[YOUR_CONFIG]/deploy/jboss-web.deployer/server.xml
<!-- Uncomment to enable request dumper. This Valve "logs interesting
contents from the specified Request (before processing) and the
corresponding Response (after processing). It is especially useful
in debugging problems related to headers and cookies."
-->
<Valve className="org.apache.catalina.valves.RequestDumperValve" />

JAAS with servlet

I am trying to use JAAS for my servlet application. I could get a basic JAAS simple authentication (non-servlet) working.
But with the servlet where to i set this variable?
-Djava.security.auth.login.config=test_jaas.config
I also tried exporting JVM_OPTS to this as per this page http://www.kopz.org/public/documents/tomcat/jaasintomcat.html
But I still keep getting, "No LoginModules configured" while creating LoginContex.
Any help is appreciated.
It depends on the servlet container. If you're using Tomcat you have to configure a JAAS realm. See the Tomcat configuration documentation under Realms.
instead you can go to java_home/conf/security/java.security and add your config location by adding the following
login.config.url.1=file:[test_jaas.config path]

How to set Axis2 Web Service Client configuration using axis2.xml?

The documentation for Axis2 mentions axis2.xml file for configuration transport settings. However I could not seem to set transport type from HTTP/1.1 to HTTP/1.0 without chunking. I have put axis2.xml file in the classpath, in the same directory but no luck. Where should I put this configuration file in order to change the transport settings?
I believe that the axis2.xml file location can specified as a jvm property parameter:
java MyApp -Daxis2.xml="location of axis2.xml"
or by creating a ConfigurationContext using a ConfigurationContextFactory and passing this to the ServiceClient constructor
you should be able to create a configuration context from the axis2.xml and set it as given above. But your requirement is just to use http 1.0 you can do that like this as well.
serviceClient.getOptions().setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_10);

Categories

Resources