Buscar este blog

sábado, 26 de noviembre de 2016

Apache CXF - Hide service list

Apache CXF generates an HTML page in which you can see all SOAP and REST services published. This is very useful when developing, but may not be suitable por a Production enviorement because this page shows to much info about your system.

For example, if you have this servelt config in web.xml file:
<servlet>
 <servlet-name>ApacheCXF</servlet-name>
 <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>  
 <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
 <servlet-name>ApacheCXF</servlet-name>
 <url-pattern>/services/*</url-pattern>
</servlet-mapping>

The CXF info page will be: http://domain/context/services.


In order to disable this page I found two solutions:
  1. Disable the page at all
  2. Securize the page

Disable the info page 

In the servlet configuration you have to set the parameter "hide-service-list-page" to value "false".
<servlet>
 <servlet-name>ApacheCXF</servlet-name>
 <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>  
 <init-param>
  <param-name>hide-service-list-page</param-name>
  <param-value>true</param-value>
 </init-param> 
 <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
 <servlet-name>ApacheCXF</servlet-name>
 <url-pattern>/services/*</url-pattern>
</servlet-mapping>

Securize the info page

You can allow only certain users (based on their Application Roles) see this page.
In the web.xml file add the following lines:
<security-constraint>
 <display-name>CXF services list</display-name>
 <web-resource-collection>
  <web-resource-name>CXF services list</web-resource-name>
  <url-pattern>/services</url-pattern>
  <http-method>GET</http-method>
 </web-resource-collection>
 <auth-constraint>
  <role-name>roleAdminCXF</role-name>
 </auth-constraint>
 <user-data-constraint>
  <transport-guarantee>NONE</transport-guarantee>
 </user-data-constraint>
</security-constraint>

<security-role>
 <role-name>roleAdminCXF</role-name>
</security-role>

In this way, only users with roleAdminCXF will be able to see it.

miércoles, 23 de noviembre de 2016

JBoss EAP - Exclude logging modules

If you want to pack your own logging configuration inside your web application, you need to exclude JBoss logging modules.

Create a a file called jboss-deployment-structure.xml inside META-INF folder:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
 <deployment>
  <exclude-subsystems>
   <subsystem name="logging" />
  </exclude-subsystems>

  <exclusions>
      <module name="org.apache.log4j" />
      <module name="org.apache.commons.logging" />
      <module name="org.jboss.logging" />
      <module name="org.jboss.logging.jul-to-slf4j-stub" />
      <module name="org.jboss.logmanager" />
      <module name="org.jboss.logmanager.log4j" />
      <module name="org.slf4j" />      
  </exclusions>
 </deployment>
</jboss-deployment-structure>

sábado, 5 de noviembre de 2016

Log4j diagnostic contexts

You have a cool web application with a lot of logging information. Each action the user performed logs a suitable amount of traces in the way of DEBUG, INFO, ERROR, etc.. But there are a lot of concurrent users performing the same actions and their logs messages are interleaved witch each other.

Of course you have the thread name in order to track down one specific user, but threads are poolled and so the names are. Multiple users may, at one time or another, pick the same thread and so the mess will continue.

If you are using Log4j there are two useful features called nested diagnostic contexts and mapped diagnostic contexts. In esence, Log4j allows you to insert arbitrary context information at some point in the thread execution and all subsequent logging instructions will retrieve and print that information.
In this link there are more info about thase two features.

In order to apply this in your application, one possible option would be to declare a Servlet Filter which populate the context. A useful context information could be:
  • A unique identifier
  • The user name, if any.
  • The user IP

For example, this is my ContextInfoLogFilter (I used the OncePerRequestFilter of Spring):
import java.io.IOException;

import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.log4j.MDC;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.stereotype.Component;
import org.springframework.web.filter.OncePerRequestFilter;

@Component("log4ContextFilter")
public class ContextInfoLogFilter extends OncePerRequestFilter {

 @Override
 protected boolean shouldNotFilter(HttpServletRequest request) throws ServletException {
  return request.getServletPath().startsWith("/resources/");   
 }
 
 @Override
 protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
  try {
   MDC.put("key", System.currentTimeMillis());
   MDC.put("usuario", getUsuario(request));
   MDC.put("ip", getIP(request));     
   filterChain.doFilter(request, response);
  }
  finally {
   MDC.clear();
  }
 }
 
 private String getUsuario(HttpServletRequest request) {
  if (SecurityContextHolder.getContext() != null 
    && SecurityContextHolder.getContext().getAuthentication() != null) {
   return SecurityContextHolder.getContext().getAuthentication().getName();
  }
  else if (request.getUserPrincipal() != null) {
   return request.getUserPrincipal().getName();
  }
  return "ANONYMOUS";
 }

 private String getIP(HttpServletRequest request) {
  final String ipAddress = request.getHeader("X-FORWARDED-FOR");
  if (ipAddress == null) {
      return request.getRemoteAddr();
  }
  return ipAddress;
 }
}

Remember to declare this filter after Spring Security Filter Chain, in order to have the security context.
(... Other Filters ...)
<filter>
 <filter-name>log4jContext</filter-name>
 <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
 <init-param>
  <param-name>targetBeanName</param-name>
  <param-value>log4ContextFilter</param-value>
 </init-param>
</filter>

<filter-mapping>
 <filter-name>log4jContext</filter-name>
 <url-pattern>/*</url-pattern>
</filter-mapping>


Finally, in your log config file you must configure the log pattern with the %X{property} conversion character. In my case I used "[%X{key}: %X{usuario} - %X{ip}]", which will extract the "key", "usuario" and "ip" properties from the mapped context.
You can check all conversio characters in htps://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html.

Fo example, this would be  my log4j.xml file:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">

 <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
  <layout class="org.apache.log4j.PatternLayout">
   <param name="ConversionPattern" value="%d{ISO8601} %-5p [%c] (%t) [%X{key}: %X{usuario} - %X{ip}] %m%n" />
  </layout>
 </appender>

 <appender name="LOG" class="org.apache.log4j.RollingFileAppender">
  <param name="File" value="${jboss.server.log.dir}/seguridad-presentacion.log" />
  <param name="MaxFileSize" value="10MB" />
  <param name="MaxBackupIndex" value="10" />
  <layout class="org.apache.log4j.PatternLayout">
   <param name="ConversionPattern" value="%d{ISO8601} %-5p [%c] (%t) [%X{key}: %X{usuario} - %X{ip}] %m%n" />
  </layout>
 </appender>

 (... Other log stuff ...)

 <root>
  <level value="INFO" />
  <appender-ref ref="CONSOLE" />
  <appender-ref ref="LOG" />
 </root>

</log4j:configuration>

Also, you need to keep in mind that a web application may has multiple entry points, not just a common HTTP request message. For example:
  • If the entry point is a web service you can use an interceptor to create the log context. In CXF you have this.
  • If the entry point is a EJB you can also use an interceptor as this or simply receive some information as a method parameter.

lunes, 31 de octubre de 2016

Spring MVC prevent caching static resources

Static resources like scripts or stylesheets are very good candidates for be cached by the browser. These resources don't  change during the life of the web application version, neither the adress where they are published, so there is no need to be actively fetch them in each request.

The problem is, what happen when one of these resources do change, for example, after the deployment of a new version of the web application. In this case, the browser keeps the previous resource version and the final user can't see the changes. In order to force the browser to refresh these resources, the user has to do something like Ctrl + F5, but this is quite cumbersome for the User Call Center.

That´s what happened to one of our web applications, so I started to thinking about some, more o less dirty, solution.

My first thought was to rename the resource file after each release. For example, if I have a /resources/css/styles.css file, I would rename it to styles-1.4.0.css file. In this way, when the resource was called from a HTML, the browser would interpret that this was a new one and made a new request.
This solution can be achieved by using Maven resource plugin, with filtering. But you have to parse all your JSP files where the resource is referenced, and also you need to rename these files to something like styles-${project.version}.css. I didn´t like.

Second try, google.
The first google solution was to use a cache control directive inside the mvc:resources configuration. You configure your resources to be valid only for a short period of time, so the browser will understand that they need to be reloaded after some time.
<mvc:resources mapping="/resources/**" location="/resources/">
    <mvc:cache-control max-age="3600" cache-public="true"/>
</mvc:resources>
This is valid, but you still depends on the browser goodwill. Besides, if your static resources don't change during the version lifespan, the browser should never reload then.

The second google solution was using Spring 4. As you can see in this good post, Spring 4 can create resources's fingeprints, so the file name is attached with some sort of hash automatically created.
This is exactly what I needed, but I was working with Spring 3. My web application had also dependencies with spring security and other spring components, so migrating all this stuff could take me some time.

Finally, I decided to make a mix with the Spring 4 aproximation and use the web application version as a query parameter. In this way, from the HTML the request will be something like http://domain/app/resources/css/styles.css?v=1.4.0

I created a custom tag (resources.tag) that is responsible for composing the full URL based on the resource path and on the application version.
<%@ tag pageEncoding="UTF-8" trimDirectiveWhitespaces="true"%>
<%@ taglib uri="http://www.springframework.org/tags" prefix="spring"%>

<%-- Parámetros --%>
<%@ attribute name="resource" required="true" description="Path del resource"%>


<spring:eval expression="@applicationProperties.getProperty('version')" var="version"/>
<spring:url value="${resource}">
 <spring:param name="v" value="${version}"/>
</spring:url>

You need to have a properties file inside the application context which holds the version key.
<context:property-placeholder properties-ref="applicationProperties" order="1" />
<bean id="applicationProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
 <property name="locations">
  <list>
   <value>classpath:conf.properties</value>
  </list>
 </property>
</bean>

And here is the conf.properties.
version = ${project.version}

(... other keys ...)

As the version property value is also a placeholder, it is Maven who sets the proper value during the build phase. You need to set your configuration in the pom.xml file.
<build>
 <resources>   
  <resource>
   <directory>src/main/resources</directory>
   <includes>
    <include>conf.properties</include>    
   </includes>
   <filtering>true</filtering>
  </resource>
 </resources>

 <plugins>
  <plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>2.3.2</version>
   <configuration>
    <source>${java-version}</source>
    <target>${java-version}</target>
   </configuration>
  </plugin> 

  <plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-resources-plugin</artifactId>
   <version>2.5</version>
   <configuration>
    <encoding>UTF-8</encoding>
   </configuration>
  </plugin>

  (... Other plugins ...)
 </plugins>
</build>

Finally, inside your JSP, when you need to reference a static resource, you only need to use your custom resources.tag:
<link rel="stylesheet" type="text/css" href='<custom:resources resource="/resources/css/styles.css"/>'/>

domingo, 30 de octubre de 2016

JBoss - Spring URL UTF-8 encoding

If you need to pass special characters in the request parameters, the browser will encode them by using the specified encoding. This is the case, for example, when using the JQuery serialize method to compose a URL with the elements inside a form.

In my case, the problem arose when I was trying to load a jqGrid base table. The user fills some fields inside a form and when she presses the search button, a jqGrid is created and a request is sent to a Spring MVC Controller.
$("#myGrid").jqGrid({
      url: '/myapp/mypage/search?+ $('#myForm').serialize(),
      loadonce:true,
      mtype: 'GET',
      datatype: "json",
      (...)
});

When some field inside "myForm" has special characters, for example 'áéíóú', the URL generated will be as follows:
http://localhost:8080/myapp/mypage/search?descripcion=%C3%A1%C3%A9%C3%AD%C3%B3%C3%BA&_search=false&nd=1477817915534&rows=20&page=1&sidx=&sord=asc
These values are the result of converting the input text to UTF-8. Inside the controller you would see ANSI characters but the application is expecting UTF-8.

The solution is to configure URI encoding in JBoss EAP 6.2 connector using the following standalone.xml configuration:
<system-properties>
     <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
     <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>
</system-properties>

In domain mode you can configure these properties at server level or server group level.
There are more useful JBoss properties I collected in a previous post: http://trabajosdesisifo.blogspot.com.es/2015/12/jboss-useful-system-properties.html

Anyway, if you are working with UTF-8, don't forget the the Spring CharacterEncodingFilter.